What you hit in week one
An API contract says what a request looks like. This page says how the system behaves when things are not ideal — restarts, disconnects, dropped messages, your own quotes crossing. Every one of these shows up in the first week.
For a period after a restart the engine accepts only orders that rest, and aggressive orders are rejected. The window length is a deployment setting; it survives restarts and round-trips through snapshots, so it is not a one-off startup blip.
What to doAfter reconnecting, quote post-only first and only release taker flow once aggressive orders go through. Treat these rejections as an expected state rather than an outage, or you will trip your own circuit breaker.
If your own quotes cross, they **really trade and really pay fees**. There is no self-trade prevention in the matching layer; the rebate layer has its own policy, under which a self-trade may be excluded from rebates or flagged for manual review.
What to doAvoid crossing yourself on the quoting side; do not rely on the server to catch it. Sustained self-trading not only burns fees but also pushes the account into the review queue.
Subscribing to `market:{id}:book` yields a one-shot snapshot followed by deltas. `market:{id}:trades` and the info topics **send no snapshot** and only stream messages from the moment you subscribe. The account topics are `account:{trader}:orders` / `positions` / `fills`.
What to doMaintain the book from the snapshot plus deltas; backfill trades and account streams over REST rather than expecting history at subscribe time.
The stream service offers no resume point and no gap replay. A dropped message is simply gone: the server will not notice and will not backfill it for you.
What to doWhen your local state looks suspect, **resubscribe** for a fresh snapshot instead of trying to resume. Re-subscribing is far cheaper than patching a book that has drifted.
Cancel-on-disconnect on the market-maker line: miss the heartbeat window and the server cancels every resting order you own. Deregistering the heartbeat explicitly does **not** trigger a mass cancel — what happens to your quotes when you stop is your call.
What to doSend heartbeats at no less than twice the window rate to leave room for jitter. Deregistration is idempotent: `removed=false` means there was nothing registered, not an error.
The off-chain engine supports FOK fully: fill in full or reject the whole order. But **a FOK order carrying an on-chain signature fails at settlement** — the settlement contract treats FOK as a reserved value and aborts, and this layer will not stop you: the order is accepted normally, returns 202, freezes funds, and then stalls at settlement.
What to doUse GTC or GTD for signed orders. Reserve FOK for unsigned off-chain orders.
When you take the cursor from a write and query status, the projection trailing by a few milliseconds is normal. The 404 you get back is **byte-for-byte indistinguishable** from “no such order”.
What to doRetry with the same cursor. Do not read the first 404 as a failed placement and resend — that becomes two orders, unless you supplied a clientOrderId.
Rate limits and tiers are on Limits & fees; which errors are safe to retry is on Errors; subscription and frame formats are on Real-time data.
