Skip to main content

Error Handling

All API errors follow a consistent format, making it easy to handle failures programmatically.

Error Response Format

Every error response includes:
Always include the requestId when contacting support — it helps us trace the exact request in our logs.

Job Error Codes

These errors occur when working with jobs, models, and user operations:

Authentication Error Codes

These errors occur during authentication and authorization:

Retry Strategy

Not all errors should be retried. Use the HTTP status code to determine the right approach:

Retryable Errors

1

503 Service Unavailable

Temporary server issue. Retry with exponential backoff:
Start with 1 second, max 60 seconds, up to 5 attempts.
2

429 Too Many Requests

Rate limit hit. Check the retryAfter field in the response and wait the specified duration before retrying.
3

500 Internal Server Error

Unexpected server error. Retry with exponential backoff, but limit attempts. If it persists, contact support.

Non-Retryable Errors

Implementation Examples

Best Practices

Log Request IDs

Store the requestId from every response for debugging and support requests.

Handle Gracefully

Always check success field before accessing data. Never assume a request succeeded.

Use Estimate First

Call the estimate endpoint before submitting to catch INSUFFICIENT_BALANCE early.

Monitor Error Rates

Track error codes in your application to identify patterns and potential issues.