Error format
The API uses RFC 7807 Problem Details format for all error responses:| Field | Description |
|---|---|
type | URI identifying the error type |
title | Human-readable summary |
status | HTTP status code |
detail | Specific explanation for this occurrence |
instance | URI identifying this specific request |
errors | Field-specific validation errors (for 400 responses) |
Validation errors
When request validation fails, the response includes field-specific errors:HTTP status codes
| Status | Meaning | Common Causes |
|---|---|---|
400 | Bad Request | Invalid parameters, malformed JSON, missing required fields |
401 | Unauthorized | Missing or invalid API key, expired key |
402 | Payment Required | Insufficient credits for the requested operation |
404 | Not Found | Resource doesn’t exist or doesn’t belong to you |
429 | Too Many Requests | Rate limit exceeded (see Rate Limits) |
500 | Internal Server Error | Unexpected server error |
Error types
| Error Type | Status | Description |
|---|---|---|
authentication_error | 401 | General authentication failure |
empty_api_key | 401 | Authorization header present but empty |
invalid_api_key | 401 | API key is invalid or revoked |
missing_authentication | 401 | No authentication credentials provided |
verification_failed | 401 | API key verification failed |
insufficient_scope | 403 | API key lacks required permissions |
validation_error | 400 | Request body validation failed |
insufficient_credits | 402 | Not enough credits for the operation |
rate_limit_exceeded | 429 | Too many requests in the current window |
not_found | 404 | Requested resource not found |
internal_error | 500 | Unexpected server error |
Handling errors
We recommend implementing retry logic with exponential backoff for429 and 500 errors:

