Use this file to discover all available pages before exploring further.
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)
{ "error": { "origin": "router", "message": "Provider and/or model not supported" }}
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.
Errors originating from upstream providers (OpenAI, Anthropic, Google, Bedrock, etc.), translated and normalized by Requesty.
HTTP Code
Origin
Error Message
Description
What to Do
429
provider
Too many requests
The upstream provider returned a rate limit error.
Reduce request frequency, or create a Routing Policy to automatically failover to another provider.
502
provider
Provider is down: Bad Gateway
The upstream provider returned a 502 error.
Retry after a short delay. Consider setting up a Fallback Policy for automatic failover.
502
router
There was a problem with the provider stream
The provider sent an error within an SSE stream after streaming had started.
Retry the request. If consistent, try a different provider or model.
503
router
The provider timed out, please try again
The upstream provider did not respond within the timeout window.
Retry the request. For long-running requests, consider models with higher timeout allowances or use a fallback policy.
424
router
Invalid provider response format
The provider returned a response that Requesty could not parse.
Retry the request. This is typically a transient provider issue. If persistent, contact support.
424
router
Provider response missing usage
The provider did not include token usage data in the response.
Retry the request. This is a transient provider issue.
529
provider
The provider is overloaded, please try again
The upstream provider is experiencing high load (common with Anthropic).
Wait and retry, or use a fallback policy to route to an alternative provider automatically.
504
provider
Provider is down: Gateway timeout
The upstream provider returned a 504 Gateway Timeout.
Retry after a short delay. Set up automatic failover with a Routing Policy.
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.
Where the error originated — "router" for Requesty errors, "provider" for upstream provider errors.
error.message
string
A human-readable description of the error.
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).
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.