Redeem an invite code
Redeems a single-use invite code.
- bound as a referee of the invite code’s owner (same effect as
POST /v1/affiliate/registerAffiliateunder the owner’s referral code), and - granted perps trading access (a second avenue beside the static API access whitelist; effective within the grant propagation interval, typically under 30 seconds).
409.
Requirements: the code’s owner must currently hold a referral code, the caller must not already have a referrer, self-redemption is rejected, and the standard registration volume gate applies.
Retry-safe: every step is idempotent. If the response is a 502 (”… retry to complete”), the code is claimed by the caller and retrying the identical request completes the redemption.
Guessing guard. Invite codes are short, so this endpoint enforces a tight budget on attempts that name a code which does not exist, on top of the standard rate limit. A caller who submits several unknown codes in quick succession receives 429 with Retry-After; the budget is not consumed by successful redemptions.Authorizations
Hex-encoded Ed25519 public key (64 chars). The public key IS the API key — register it via POST /createApiKey. Required on every authenticated request, both read-only and signed.
Unix time in nanoseconds as a decimal string (e.g. "1713825891591000000"). Millisecond or second epochs are rejected with 401 Unauthorized. Must be within ±30,000 ms (MaxTimestampDriftMs, the drift window stays configured in milliseconds) of server wall-clock, or the request is rejected with 401 Unauthorized. Required on all mutating / credential-creating endpoints. This same value must appear as the ct field in the ordersign typed canonical payload (single-order endpoints) or in each element's ct field (batch endpoints).
Lowercase hex-encoded Ed25519 signature (128 chars).
Single-order endpoints (placeOrder, cancelOrder, modifyOrder, and other non-batch mutating routes) sign over the ordersign typed canonical payload — a compact, key-sorted JSON object built from parsed request fields using engine-native integer values:
ct must equal the X-Timestamp header value. Keys in brackets are conditional (omitted when empty). op values: 1=place, 2=cancel, 3=modify. See the ordersign package for field definitions and reference signing code.
Other signed routes (e.g. createApiKey, tokens, userPreferences) still use the legacy scheme: signing_message = X-Timestamp + ACTION + canonicalJSON(body), where ACTION is the camelCase final path segment.
Batch endpoints (batchPlaceOrders, batchCancelOrders) do NOT use this header. They authenticate with per-element typed ordersign signatures embedded in the request body (see the global auth description and the per-field signature descriptions on OrderRequest / CancelOrderRequest).
Read endpoints are authenticated by ?address= (and optionally X-API-Key) only — no signature is required. The one exception is GET /v1/affiliate/inviteCodes, which returns bearer secrets and therefore requires the full header triple; with no body its signing message is X-Timestamp + ACTION. canonicalJSON(body) is the JSON body with object keys sorted lexicographically at every level and no whitespace; the server canonicalizes the received body before verifying, so only the bytes signed over must be canonical. Required on all mutating / credential-creating endpoints.
Body
Ethereum address of the redeemer (must match signer).
Invite code to redeem. The canonical form is 6 uppercase base36 characters (A-Z, 0-9); any casing is accepted, and spaces and dashes are stripped so a code copied from a chat message works as sent.
1 - 32Response
Redemption confirmed by the matching engine (referee binding ack received within the server-side timeout). Trading access follows within the grant propagation interval.