error key containing the type, code, human-readable message, and (where applicable) the parameter that caused the error.
Error response format
Every error response has this shape:Error types
Error types group errors into broad categories. Use these for top-level error handling.Error codes
Error codes provide specific, machine-readable identifiers for each error condition.Request validation errors
Authentication and authorization errors
Resource errors
Rate limiting and idempotency errors
Server errors
HTTP status codes
Example error responses
Missing required field
Invalid Ethereum address
Authentication failure
Insufficient permissions
Resource not found
Rate limit exceeded
Idempotency conflict
Handling errors in code
TypeScript / JavaScript
Python
Best practices
Always check the error type first
Always check the error type first
Use
error.type for broad control flow (e.g., retry on rate_limit_error, fail fast on authentication_error). Use error.code for specific handling within a type.Use the param field to build form validation
Use the param field to build form validation
When
error.param is present, you can map it directly to a form field to show inline validation errors in your UI.Implement retry logic for transient errors
Implement retry logic for transient errors
rate_limit_error and api_error (500) are transient. Use exponential backoff when retrying:Never retry 4xx errors (except 429)
Never retry 4xx errors (except 429)
Client errors like
400, 401, 403, and 404 will not resolve on retry. Fix the request or credentials before retrying.Log the full error object for debugging
Log the full error object for debugging
Always log
error.type, error.code, error.message, and error.param together. This gives you the full picture when debugging production issues.
HypeDuel