POST /api/v1/qr

Render a base64 PNG QR code for the order pay-in address.

POST/api/v1/qrAuth required

Returns a base64 PNG data: URL of the order’s pay-in address, rendered at 256×256 with error-correction level M and a 2-module quiet zone. Drop the value directly into an <img src="…"> to show the deposit QR inline.

Caching. Successful responses are served from a one-hour server-side cache. The cached PNG is immutable per order, and every call is gated by partner ownership before the cache is consulted.

Request

Body
idstring (UUID)required
Order id from /api/v1/create. Same field name as /api/v1/order and /api/v1/emergency.
tokenstring (43-char base64url)required
Raw access token. Same verification contract as /api/v1/order; any mismatch returns code 6 NOT_FOUND.

Response

200 OK
{
  "code": 0,
  "msg": "",
  "data": {
    "qrPng": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAQAAAAEACAYAAA..."
  }
}
Fields
data.qrPngstring (data: URL)
data:image/png;base64,… of the rendered QR. The encoded payload is the raw pay-in address; the address itself never appears in this response and must be fetched from data.from.address on /api/v1/order.

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.
99INTERNAL500Unexpected server-side condition. Already logged on our side; safe to retry.

Code examples

# Returns base64 PNG data URI of the order's pay-in address.
APIKEY="rWqZ...Rg"
APISECRET="G1JV...n4"
NONCE=$(openssl rand -hex 16)
BODY='{"id":"1f8c5e0b-9c92-4d6a-b0a8-3c5f8d6e7a4b","token":"v8k3-Po9...43-char-base64url"}'
SIGN=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$APISECRET" | sed 's/^.* //')

curl -sS -X POST "https://0trace.io/api/v1/qr" \
  -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 5 per call. 5 weight units per call (heavier than /api/v1/order's 1 because PNG generation is CPU, lighter than /api/v1/create's 50).

Notes

Soft-deleted orders. Cached QRs are not served for soft-deleted orders. The route re-checks visibility on every call, even when the cache would otherwise hit. The response collapses to code 6 NOT_FOUND in that case.

No raw address in the body. Use this endpoint when you want a QR. Use /api/v1/order when you want the text address. They are separate so a UI that only renders a QR does not need to handle the address string format.

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