Skip to main content
Hypermid uses a consistent error format across all endpoints. This guide covers every error code and the recommended strategy for handling each one.

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 a RATE_LIMIT error, use the meta.rateLimit.reset timestamp to wait before retrying:

No Route Found

When NO_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

  1. Always check response.error — Never assume a 200 status means success without checking the error field.
  2. Log requestId — Store the meta.requestId for every failed request. This is essential for debugging with support.
  3. Implement circuit breakers — If you see repeated 5xx errors, temporarily stop making requests to avoid wasting rate limit quota.
  4. Show user-friendly messages — Map error codes to messages appropriate for your users, not the raw API error message.
  5. Monitor rate limits proactively — Track meta.rateLimit.remaining and slow down before hitting the limit.