Error Response Format
All errors follow the standard response envelope:Always include the
meta.requestId when contacting support about an error. This allows the team to trace the exact request through the system.Error Codes Reference
Client Errors (4xx)
Server Errors (5xx)
Handling Strategies
Retry with Exponential Backoff
For transient errors (INTERNAL_ERROR, UPSTREAM_ERROR, RPC_FAILURE, SERVICE_UNAVAILABLE, TIMEOUT, UPSTREAM_TIMEOUT), implement exponential backoff:
Rate Limit Handling
When you receive aRATE_LIMIT error, use the meta.rateLimit.reset timestamp to wait before retrying:
No Route Found
WhenNO_ROUTE_FOUND is returned, the swap cannot be executed with the given parameters. Try these strategies:
Slippage Error
When price moves beyond the tolerance during execution:Comprehensive Error Handler
Here’s a production-ready error handler that covers all cases:Best Practices
-
Always check
response.error— Never assume a 200 status means success without checking the error field. -
Log
requestId— Store themeta.requestIdfor every failed request. This is essential for debugging with support. - Implement circuit breakers — If you see repeated 5xx errors, temporarily stop making requests to avoid wasting rate limit quota.
- Show user-friendly messages — Map error codes to messages appropriate for your users, not the raw API error message.
-
Monitor rate limits proactively — Track
meta.rateLimit.remainingand slow down before hitting the limit.