Retries & Backoff
Retries & Backoff
The SDK includes built-in retry logic with exponential backoff for transient failures. Retries are configured globally on the client and can be overridden per request.
Default behavior
By default, the SDK retries on these status codes:
4xx errors other than 429 (client errors like 400, 401, 403, 404) are not retried — they indicate a problem with the request itself.
Global configuration
Set retry behavior when creating the client:
Per-request override
Override the retry config for a specific call:
Backoff strategy
The SDK uses exponential backoff with jitter:
The random jitter (0-1000ms) prevents thundering herd issues when multiple clients retry simultaneously.
Retry-After headers
When the server returns a Retry-After or Retry-After-Ms header (common with 429
responses), the SDK respects it — the header value overrides the calculated backoff delay.
Disabling retries
Next steps
- Error Handling — catch and handle errors that survive retries
- Idempotency — understand safe retry behavior for commands