POST /api/v1/emergency

Resolve an order in EMERGENCY status — continue at the live rate.

POST/api/v1/emergencyAuth required

Resolves an order whose partner-facing status is EMERGENCY. Sending choice = "EXCHANGE" instructs us to resume processing at the current live rate. The order continues through its normal lifecycle and your integration takes no further action.

Orders that cannot be resolved through EXCHANGE (rate volatility, deposit anomaly, or any other manual-review trigger) are finalised by the operator. The terminal state surfaces through order.status_changed as status EXPIRED.

Request

Body
idstring (UUID)required
Order id from the original /api/v1/create response.
tokenstring (43-char base64url)required
Raw access token, verified against a stored hash. Mismatch, cross-partner, or missing all collapse to code 6 NOT_FOUND.
choice"EXCHANGE"required
Case-sensitive. Any other value returns code 12 EMERGENCY_INVALID_CHOICE.

Response

200 OK
{
  "code": 0,
  "msg": "",
  "data": true
}
Fields
databoolean
Always true on success. The choice has been persisted and we will act on it shortly.

Errors

codemsgHTTPDescription
1INVALID_REQUEST400Body fails validation: unsupported asset, disabled pair, unparseable amount, invalid address, FLOAT without refundAddress, malformed Idempotency-Key. The same code + HTTP 409 fires on Idempotency-Key reuse with a different payload.
2AUTH_REQUIRED401One of X-API-KEY / X-API-SIGN is missing on an endpoint that requires authentication.
3AUTH_INVALID401Unknown key, malformed signature, signature mismatch, expired or replayed nonce, decrypt failure. Generic body — never an oracle for "which" of those it was.
4AUTH_DISABLED401Partner record enabled = false. Reachable only with a valid signature, so the operator can distinguish a kill-switched partner from a stolen-and-revoked key.
5RATE_LIMIT429Per-partner weight budget exhausted within the 60-second sliding window. Response includes Retry-After: <seconds>.
6NOT_FOUND404Order does not exist OR exists but belongs to a different partner OR exists and the token is wrong. The three cases collapse to one envelope.
12EMERGENCY_INVALID_CHOICE400POST /api/v1/emergency body has `choice` other than `EXCHANGE`.
99INTERNAL500Unexpected server-side condition. Already logged on our side; safe to retry.

Code examples

# Resolve an order in status = "EMERGENCY" by resuming at the live rate.
APIKEY="rWqZ...Rg"
APISECRET="G1JV...n4"
NONCE=$(openssl rand -hex 16)
BODY='{"id":"1f8c5e0b-9c92-4d6a-b0a8-3c5f8d6e7a4b","token":"v8k3-Po9...43-char-base64url","choice":"EXCHANGE"}'
SIGN=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$APISECRET" | sed 's/^.* //')

curl -sS -X POST "https://0trace.io/api/v1/emergency" \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: $APIKEY" \
  -H "X-API-SIGN: $SIGN" \
  -H "X-API-NONCE: $NONCE" \
  --data "$BODY"

Rate limit

Weight 1 per call. Counts against the default 2500 weight-unit / minute sliding-window budget per partner.

Notes

Status guard. The order must currently be in EMERGENCY. A call against an order in any other state returns { code: 1, msg: "order not in emergency state" } with HTTP 400. No further detail is exposed via this endpoint. Poll /api/v1/order to resynchronise.

Partner API.
Same engine as 0trace.

A private partner integration surface. Signed quotes, server-side pricing, webhook delivery, multiple reference codes, and a self-serve cabinet — all backed by the production exchange engine.

Need help?

Questions? Answers.

A partner integration surface on top of the same exchange engine that powers 0trace.io. You connect with a signed REST contract, query quotes, open orders, and receive webhook notifications. Our liquidity, our pricing, our payouts. You focus on your product.
No. The API is private and invite-only, aligned with the privacy posture of 0trace itself. There is no KYC, no identity collection, and no source-of-funds reporting required of partners or their end users.
Submit a request through our partner application form at 0trace.io/api/contact-sales and we’ll reply within three business days.
Traffic is encrypted in transit (TLS). Every request is signed with HMAC-SHA256 over the exact request body bytes and gated by a nonce-based replay window. Pricing, fees, and payout amounts are computed server-side. Payouts run on an isolated service that re-verifies each transfer against the on-chain deposit before broadcasting.
A per-partner sliding-window weight budget, default 2500 wu/min (≈50 creates/minute). Endpoint weights: /api/v1/create is 50, /api/v1/qr is 5, every other endpoint is 1. XML feeds run on a separate public bucket. Exceeding the budget returns 429 with a Retry-After header. To raise your cap, send your projected per-endpoint call rate to your operator contact.
Two ways to earn. Revenue share: send us traffic with your referral link and earn a share of our service fee on every order — the visitor sees our live rate. Markup: integrate through the API and add your own margin on top of our rate, shown in your own interface. Use either, or both.
Yes. 0trace operates its own liquidity pool across every supported asset and network. Quotes are recomputed server-side at order creation against the live feed. Payouts are direct, with no third-party intermediary.
Bitcoin, Ethereum, BSC, Solana, Tron, Monero, and Arbitrum One — covering native coins plus the major stablecoins on each network (USDT, USDC, USDC.e).
Yes. We push signed events for order.status_changed and partner.paid_out; you subscribe to the ones you want in your cabinet.

Follow us on X for the latest updates.

Subscribe