Skip to main content
Reader returns 11 stable error codes. Your retry logic should branch on error.code, not on HTTP status or error message. This guide gives you the exact rules.

The retry matrix

The JS and Python SDKs implement this matrix automatically. Transient codes get retried with exponential backoff; permanent codes throw immediately.

Manual retry (no SDK)

If you’re calling the HTTP API directly:

Backoff schedules

The classic exponential schedule with jitter:
For Reader, reasonable values:
  • base = 1 second
  • jitter = 500ms
  • Cap total retries at 3–5 for interactive calls, 10+ for background workers
Jitter matters when many workers hit a rate limit at the same time; without it they all retry on the exact same schedule and keep colliding.

Logging

When you give up on a retry, log the full error envelope:
The requestId is the critical field for support tickets: it lets Reader’s logs find your exact request.

Circuit breakers

For production workers, add a circuit breaker on top of retries: if the last N requests all failed, stop trying and alert. Otherwise a sustained Reader outage causes your worker to retry forever and drive your rate limit through the floor.

Next