Skip to content
PrefactorPrefactorPrefactor Docs

Handle rate limiting

Prefactor rate limits requests to the platform API — Rate limits covers how limits are applied and what a limited response contains. Both SDKs treat a rate-limited response as transient and retry it for you; this page covers what those retries look like and what you see when they run out.

Automatic retries

Section titled “Automatic retries”

When Prefactor returns 429, both SDKs wait and retry the request with exponential backoff and jitter. The defaults retry three times — about a second after the first failure, doubling from there, capped at a minute — and suit most applications. You can tune them through the HTTP config fields (maxRetries, initialRetryDelay, maxRetryDelay, retryMultiplier; the same names with underscores in Python) described in Configuration and environment variables.

The SDKs back off on their own schedule rather than reading the Retry-After hint the server sends. Because limits are counted over one-minute windows, the default retries can all land inside the same window — if retries keep running out under sustained load, raise the initial delay or the retry count.

TypeScript: when retries run out

Section titled “TypeScript: when retries run out”

If a request is still limited after the last retry, the transport treats it as fatal. It records a PrefactorFatalError with kind retry_exhausted, stops sending telemetry, and later telemetry calls throw the same error. If you set the failureHandling.onFatalError callback, it fires once with the error — that is the place to alert or restart the run.

Python: when retries run out

Section titled “Python: when retries run out”

After the HTTP client’s own retries run out, the queue worker retries the whole operation again before dropping it: the worker logs the failure and moves on to the next item. The client is not latched, so later spans and operations are sent as normal.

Section titled “Related”