Skip to main content
POST
Redeem an invite code
The response body shown here is a static example, not live data. After you click Send, your live result appears in a separate panel headed 200 OK. The panel under the status-code tabs is a fixed sample from the spec — its field values (fees, prices, sizes, IDs, timestamps) are placeholders. Use Send, or call the endpoint, for current values.
Redeems a single-use invite code. On success the caller is:
  • bound as a referee of the invite code’s owner (same effect as POST /v1/affiliate/registerAffiliate under 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).
The invite code is marked used atomically — if two callers race on the same code, exactly one wins and the other receives 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

X-API-Key
string
header
required

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.

X-Timestamp
string
header
required

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).

X-Signature
string
header
required

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

application/json
address
string
required

Ethereum address of the redeemer (must match signer).

inviteCode
string
required

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.

Required string length: 1 - 32

Response

Redemption confirmed by the matching engine (referee binding ack received within the server-side timeout). Trading access follows within the grant propagation interval.

status
enum<string>
required
Available options:
submitted
referrer
string
required

Ethereum address of the invite code's owner the caller is being bound to.