Skip to main content

Response Format

All v2 error responses follow this shape:
Always match on the code string, not the HTTP status or message text. The code values are a stable enum and won’t change without a breaking version bump.

Special Response Shapes

Validation errors include a fields object with per-field details:
Rate limit errors include retry metadata:

Error Codes by Endpoint

GET /v2/quotes

POST /v2/exchanges

GET /v2/orders/{houdiniId} and GET /v2/orders

Global Errors (all endpoints)

These can be returned by any endpoint:

HTTP Status Summary


Best Practices

  1. Match on code, not message — The code field is a stable string enum. Messages may contain dynamic values and can change without notice.
  2. Use regex for dynamic messages — For codes like QUOTE_OVER_LIMIT, AMOUNT_TOO_LOW, SWAP_AMOUNT_IS_OUT_OF_BOUNDS, extract the dynamic part with a regex:
  3. Handle 422 as your primary error status — Most business logic errors return 422, not 400 or 500.
  4. Respect retryAfter — On 429 responses, wait the specified number of seconds before retrying. The meta object provides additional context about which limit was hit.
  5. Log requestId — Always log the requestId from error responses. Include it when contacting support for faster debugging.
  6. Implement exponential backoff for 500/503 — These are transient errors. Retry with backoff (e.g. 1s, 2s, 4s) up to 3 attempts.
  7. Don’t retry 422 errors — These are deterministic. The same request will produce the same error. Fix the input before retrying.

Need Help?

API v2 Reference

Complete endpoint documentation

Order Lifecycle

Understand order states

Quick Start

Integration guides for each swap type

Contact Support

Get help with specific issues