Skip to main content
A reliable client treats the API as a bounded queue, not an unbounded loop. Five patterns cover almost every production REST job.

​
Retry the right failures

Honor Retry-After when a 429 includes it. When it is absent, use capped exponential backoff with jitter and lower concurrency before trying again. Do not retry unchanged after a 4xx that means the request is wrong: authentication, account state, malformed request, unsupported symbol, or invalid parameter. Those will fail again the same way. Fix the request or the key first, then resume. Treat 5xx and network errors as transient and retry with backoff.

​
Log a request handle on every call

Capture meta.request_id from the envelope, or the x-request-id response header when a route returns a resource-specific body instead of the envelope. Log it on success and on failure. A stored request id is what makes a slow or failed call reviewable later, and it is the first thing support will ask for.

​
Bound concurrency to the plan

Each plan sets a concurrent-query ceiling. Size worker pools to it and queue the rest. Isolate heavy routes such as L4, deep history, and large windows from light status checks so one slow worker does not stall the whole pipeline. See Rate limits for the per-plan numbers.

​
Reads are safe to repeat

Historical, bounded GETs are safe to repeat at the transport level. A request for a moving latest snapshot can change between attempts, so pin timestamp or a fixed start/end window when you need identical input. Repeating a GET does not mutate server state, but it does not make an unbounded current read immutable. Pair retries with Pagination so a resumed run continues from its last cursor; deduplicate at the application boundary when a retry can overlap a page.

​
Gate on data quality

Before a window feeds a backtest, alert, export, or model, confirm it is trustworthy. Check coverage, freshness, gaps, and incidents on Data quality. A clean-looking response over an incomplete window is the failure mode that quietly corrupts downstream work; the data-quality routes are how you catch it before it ships.

​
Probe, then widen

One BTC order-book request confirms auth and envelope shape. One bounded trade window confirms pagination and schema. Only after those pass should a job widen across symbols or longer history. Keep the route family, window, page size, concurrency, and retry budget in the job config so any run can pause, resume, and be explained.
Last modified on August 28, 2026