Keep a production REST job correct when calls fail: retry only what can succeed, log a request ID on every call, bound concurrency to your plan, and check data quality before results are used. Treat the API as a bounded queue of work, not an unbounded loop.
Retry the right failures
Retry a 429 with error_code rate_limited within a budget: after its retry_after seconds for the request rate, or when an in-flight request finishes for concurrency. Stop on insufficient_credits. A 503 carries a Retry-After header. When you reach a limit has the full rule.
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 ID 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.
Repeat reads safely
Historical, bounded GET requests 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 complete enough for the job. Check coverage, freshness, gaps, and incidents on Data quality. A clean-looking response over an incomplete window is the failure that quietly corrupts downstream work; the data-quality routes 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.
Next step
Decide what to do with each error_code on Errors. Last modified on October 6, 2026
