Skip to main content
When a request fails, Requesty returns a standard JSON error response with an HTTP status code and a human-readable message. Errors originate from either the router (Requesty’s own validation and routing logic) or an upstream provider (OpenAI, Anthropic, Google, etc.).
Example error response (HTTP 404)
The origin field tells you where the error came from — "router" means Requesty caught the problem before it reached a provider, while "provider" means an upstream LLM provider returned the error.

Authentication & Authorization

Errors related to API key validation, account status, and access control.

Request Validation

Errors returned when the request payload is malformed or contains invalid parameters.

Model & Routing

Errors related to model resolution, routing policies, and plan compilation.

Provider Errors

Errors originating from upstream providers (OpenAI, Anthropic, Google, Bedrock, etc.), translated and normalized by Requesty.
Requesty automatically retries provider errors when you use a Routing Policy with multiple models. Provider rate limits (429), overload (529), timeouts (503), and bad gateway (502) errors all trigger automatic fallback to the next model in the chain.

Rate Limiting


Security & Guardrails


Connection & Client Errors


Internal Errors


Context Length Errors

When your input exceeds a model’s context window, Requesty translates the provider-specific error into a clear, actionable message.

Error Response Format

All errors return JSON with the following structure:
The HTTP status code is returned in the response status line (e.g., HTTP/2 404). The origin field helps you determine whether to fix your request (router) or retry / failover (provider).
HTTP 400

Best Practices

Use Routing Policies

Set up fallback chains so provider errors (429, 502, 503, 529) automatically retry on a different model — your application never sees the error.

Set Spend Limits

Configure per-project or per-key spend limits to avoid unexpected 402 errors from balance exhaustion.

Monitor with Logs

Use the Logs view to inspect individual request errors, filter by status code, and debug issues in real time.

Check the Model Library

Verify model names, providers, and capabilities before making requests to avoid 404 and 400 errors.
Track errors in Advanced Analytics. Group by status_code in Advanced Analytics to see which errors are costing you the most and spot trends over time.
Include request IDs in support tickets. Every response includes an x-request-id header. When contacting support, include this ID so we can trace the exact request path through the router.

Error Recovery and Retry Strategy

Implement exponential backoff with jitter for retryable errors. The following strategy works for all Requesty API calls:
Use routing policies for automatic recovery. Instead of implementing retry logic in your application, create a routing policy with multiple models. Requesty automatically retries on provider errors (429, 502, 503, 529) using the next model in your fallback chain.
Last modified on June 6, 2026