GET /orders, GET /orders/paginated or GET /orders/{id}, so you do not need to poll until it appears or sleep between writing and reading. Those reads wait for the read model to catch up, bounded at 1 second by default. If that bound expires the request is still answered, with what has been written so far, which may be missing your most recent write; re-read rather than re-sending the write. GET /orders/events reads a different table and is outside this guarantee.
List Orders
API key HMAC
Query parameters:
Response type:
OrderWithMarket[].
When status is omitted, the endpoint returns all non-cancelled statuses. Passing status=CANCELLED returns 400.
Can return 503 with error: "ORDER_READS_UNAVAILABLE". See Order Read Errors.
List Orders Paginated
API key HMAC
Query parameters:
When
status is omitted, this endpoint returns active orders only: PENDING and EXECUTING.
Response type: OrderPagination.
Can return
503 with error: "ORDER_READS_UNAVAILABLE". See Order Read Errors.
Get Order
API key HMAC
Path parameters:
Response type:
OrderWithMarket.
Can return 503 with error: "ORDER_READS_UNAVAILABLE". See Order Read Errors.
Create Order
API key HMAC
Request body type: CreateOrder.
Do not send
priceUint. The server sets it, and the request validator rejects a body that carries it.
Response type: Order.
This endpoint returns 503 when the order could not be signed, submitted or admitted. Every 503 here means nothing was created, so re-sending the identical body cannot duplicate the order. See Admission Errors. An insufficient balance is a 400, not a 503, and retrying it will not help.
Create Batch Orders
API key HMAC
Request body:
Response type:
CreateBatchOrdersResponse.
BatchOrderResult:
The six
errorCode values listed under Admission Errors arrive on this route as an entry’s code inside a normal 201, with no Retry-After header, because other entries in the same request may have been created. The code set is open-ended: it is whatever the venue supplies for that entry, plus local fallbacks including bad-request, internal-error, not-attempted, nonce-stale and order-archived. Do not assume the set is closed; treat an unrecognised code the way you treat internal-error.
This route can still answer a request-level 503 with error: "SIGNING_UNAVAILABLE", in which case no order in the batch was created.
Cancel Order
API key HMAC
Path parameters:
Response type:
Order.
Returns 503 with error: "ORDER_ADMISSION_UNAVAILABLE" and errorCode: "engine-busy" when the venue declined to admit the cancellation. Nothing was cancelled and the identical request can be re-sent. See Admission Errors.
Cancel Batch Orders
API key HMAC
Request body:
Response type:
BatchCancelOrdersResponse.
BatchCancelOrderResult:
A failed reply is returned as its own status rather than collapsed into a
409:
None of these carries a
Retry-After header or an errorCode. A 503 whose error is CREDENTIAL_UNVERIFIABLE is not one of them: your API key could not be checked, so the request was not attempted and nothing was cancelled. 408 and the broker’s 503 are lost-response cases: the orders may or may not have been cancelled, so re-read them before re-issuing.
Cancel Market Orders
API key HMAC
Request body:
Response type:
Order[].
Returns 503 with error: "ORDER_ADMISSION_UNAVAILABLE" and errorCode: "engine-busy" when the venue declined to admit the cancellation. Nothing was cancelled and the identical request can be re-sent. See Admission Errors.
Cancel Event Orders
API key HMAC
Cancels all of your open orders across every market in one event.
Request body:
Response type:
CancelSweepResponse. See Cancel Sweep Response.
Cancel All Orders
API key HMAC
Response type: CancelSweepResponse. See Cancel Sweep Response.
Cancel Sweep Response
POST /api/v1/orders/cancel-all and POST /api/v1/orders/cancel-event return CancelSweepResponse with a status of 200 or 207.
CancelSweepOrderResult:
For each entry where
success is false, act on code:
Entries carry no market ID.
Branch on the status first, then on
error. Do not branch on message.
Get Order Book Events
API key HMAC
Query parameters:
Response type:
Pagination<OrderbookEvent>.
When total=true, the count is bounded and the response can include totalCapped.
Order Read Errors
GET /api/v1/orders, GET /api/v1/orders/paginated and GET /api/v1/orders/{id} answer 503 with error: "ORDER_READS_UNAVAILABLE" when the server’s order-read capacity stays taken for the whole wait. The response carries a Retry-After: 1 header and retryAfterSeconds: 1 in the body. A read changes nothing, so re-send the identical request. GET /api/v1/rewards/me/qualifying-orders can answer the same 503.
Admission Errors
POST /api/v1/orders answers 503 when the order could not be signed, submitted or admitted. Every 503 on that endpoint means nothing was created, so re-sending the identical body cannot duplicate the order. Each of these responses carries a Retry-After header and repeats the same figure in the body as retryAfterSeconds.
A 503 whose error is CREDENTIAL_UNVERIFIABLE is not one of these. Your API key or JWT could not be checked, so the order was not attempted. Its body has statusCode, error and message only, with no errorCode and no retryAfterSeconds, and it carries no Retry-After header; see Authentication.
SIGNING_UNAVAILABLE carries no errorCode. It has four causes: the signing provider being unavailable, rate-limiting Hit or having no slot in Hit’s signing-admission queue; the request budget being exhausted before the order could be submitted; the duplicate guard’s store being unavailable; and, on POST /api/v1/orders/batch only, the locking infrastructure being unavailable. Three of those four — the request budget, the duplicate guard’s store, and the batch locking infrastructure — reach orders you signed yourself, so this status is not limited to orders Hit signs for you. Every batch takes its per-account lock whether or not anything in it needs signing.
ORDER_ADMISSION_UNAVAILABLE carries an errorCode:
The first four mean your collateral could not be read.
engine-busy is a stronger statement than the others: the command was not decided, not recorded and not partially applied, because the venue was at one of its own internal bounds. idempotency-unverifiable means the duplicate check could not be answered, so the venue refused rather than risk a second live order for one key.
For engine-busy and idempotency-unverifiable, re-send the identical body and do not change salt. The idempotency key is derived from the order’s contents, so a new salt is a different order and defeats the deduplication.
None of these values means your order is invalid or your balance is insufficient. A genuinely insufficient balance is a 400, and retrying it will not help.
POST /api/v1/orders/cancel-all and POST /api/v1/orders/cancel-event report a market the venue declined through results: every order in such a market that the venue had not yet decided carries code: "engine-busy", and anything it decided before declining carries its own verdict. Other markets in the same request may have been cancelled, so re-send rather than assuming either way. results entries carry no retryAfterSeconds.
Order
OrderWithMarket contains every Order field except inflightAmount, bookedAt, source and cancelSource, plus required marketInfo: OrderMarketInfo. GET /orders, GET /orders/paginated and GET /orders/{id} return this enriched shape. Order values returned by create-order, cancel-order and cancel-market endpoints use the plain Order shape. Batch and cancel-all responses use the wrapper types documented above.
OrderMarketInfo:
OrderbookEvent
OrderbookEventMarket: