POST /v1/codes
Manage multiple reference codes with per-code afftax.
Reference codes attach a per-code afftax override (and an optional free-form label) to your partner record. Callers select a code at request time via X-API-KEY: <prefix>.<code>. The auth layer looks it up, verifies ownership and enabled state, and feeds the per-code afftax into /v1/price and /v1/create.
Aggregators use codes to bill differently per surface (desktop, widget, iframe). Casinos rotate them per campaign to track conversion without issuing a new credential bundle. Default cap is 50 codes per partner. The operator can raise it on request.
Code format
- Regex:
^[A-Za-z0-9_-]{4,32}$: URL-safe alphabet, length 4..32. - No dots: the auth-side parser splits
X-API-KEYon the first.and assumes the suffix is a single segment. - Optional
labelis a free-form string up to 64 characters. Bookkeeping for you, never surfaced to end users.
POST /api/v1/codes — create
/api/v1/codesAuth requiredcodestringrequiredlabelstring | nullafftaxBpsinteger{
"code": 0,
"msg": "",
"data": {
"id": "ckxq0...",
"code": "casino-front",
"label": "Casino front-end",
"afftaxBps": 500,
"enabled": true,
"createdAt": "2026-05-13T08:42:11.000Z"
}
}# Create a new reference code with a 5% afftax. Authenticate via
# the top-level apiKey + apiSecret bundle. Callers then use
# X-API-KEY: <prefix>.<code> to attribute traffic to this code.
APIKEY="rWqZ...Rg"
APISECRET="G1JV...n4"
NONCE=$(openssl rand -hex 16)
BODY='{"code":"casino-front","label":"Casino front-end","afftaxBps":500}'
SIGN=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$APISECRET" | sed 's/^.* //')
curl -sS -X POST "https://0trace.io/api/v1/codes" \
-H "Content-Type: application/json" \
-H "X-API-KEY: $APIKEY" \
-H "X-API-SIGN: $SIGN" \
-H "X-API-NONCE: $NONCE" \
--data "$BODY"GET /api/v1/codes — list
/api/v1/codesAuth requiredReturns every code owned by the partner (enabled + disabled), newest first, capped at 100 rows. Sign an empty body "" for the request signature.
{
"code": 0,
"msg": "",
"data": [
{
"id": "ckxq0...",
"code": "casino-front",
"label": "Casino front-end",
"afftaxBps": 500,
"enabled": true,
"createdAt": "2026-05-13T08:42:11.000Z"
},
{
"id": "ckxp9...",
"code": "widget",
"label": null,
"afftaxBps": 200,
"enabled": false,
"createdAt": "2026-05-12T22:18:03.000Z"
}
]
}DELETE /api/v1/codes — soft-disable
/api/v1/codesAuth requiredcodestringrequiredDisabled codes are still listed by GET /api/v1/codes. They are rejected at authentication, so a caller using a disabled code receives code 3 AUTH_INVALID.
POST /api/v1/codes/enable — re-enable
/api/v1/codes/enableAuth requiredcodestringrequiredErrors
| code | msg | HTTP | Description |
|---|---|---|---|
| 1 | INVALID_REQUEST | 400 | Body 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. |
| 2 | AUTH_REQUIRED | 401 | One of X-API-KEY / X-API-SIGN is missing on an endpoint that requires authentication. |
| 3 | AUTH_INVALID | 401 | Unknown key, malformed signature, signature mismatch, expired or replayed nonce, decrypt failure. Generic body — never an oracle for "which" of those it was. |
| 4 | AUTH_DISABLED | 401 | Partner record enabled = false. Reachable only with a valid signature, so the operator can distinguish a kill-switched partner from a stolen-and-revoked key. |
| 5 | RATE_LIMIT | 429 | Per-partner weight budget exhausted within the 60-second sliding window. Response includes Retry-After: <seconds>. |
| 6 | NOT_FOUND | 404 | Order 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. |
| 13 | LIMIT_EXCEEDED | 403 | Partner reached the per-partner ceiling on POST /v1/codes (default 50 reference codes). |
| 99 | INTERNAL | 500 | Unexpected server-side condition. Already logged on our side; safe to retry. |
Rate limit
Every verb (POST create, GET list, DELETE disable, POST codes/enable) charges 1 weight unit against the per-partner sliding-window budget.