Example error response (HTTP 404)
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).
- Router error (your request)
- Provider error (upstream)
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.