Skip to main content
API v1 is deprecated. This version is no longer being developed — new endpoints, parameters and models are added to v2 only. Use the v2 endpoints to stay current: v2 API documentation.
v1 and v2 share the same error envelope — this page mirrors API v2 → Errors with v1 paths. deAPI uses conventional HTTP response codes to indicate the success or failure of an API request. Codes in the 2xx range indicate success. Codes in the 4xx range indicate an error from the provided information (e.g., missing required parameter, unauthorized access). Codes in the 5xx range indicate an error with deAPI servers.

HTTP Status Codes

Error Response Format

Every error response carries a top-level message. Validation errors (422) additionally carry an errors object:
string
Human-readable error description. Present on every error response. For a 422 with several failures it summarises the first one and counts the rest, e.g. "The width field must be at least 512. (and 2 more errors)".
object
Only present on 422. A map of field name → array of messages, not an array. A single request can fail on several fields at once, and a single field can carry several messages.
The error body has no data and no statusCode field — read the status from the HTTP response itself. Do not iterate errors as an array: it is an object keyed by field name (errors.model[0], not errors[0].field).

Error Types

401 Unauthorized

Returned when authentication fails. Common causes:
  • Missing Authorization header
  • Invalid API key
  • Expired or revoked API key
Solution: Verify your API key is correct and included in the Authorization: Bearer <API_KEY> header.

404 Not Found

Returned when the requested resource doesn’t exist. Two different bodies are possible. Unknown job / resource — e.g. an invalid request_id passed to GET /api/v1/client/request-status/{request_id}:
Match on the status code, not on the message text. The wording of 404 messages is not part of the API contract and can change.
Unknown route — e.g. calling a documentation URL instead of the API path:
Solution: Verify the request_id, and take API paths from the API Overview — documentation URLs are not API routes (the real balance route is /api/v1/client/balance).
An unknown model is not a 404 — it fails validation and returns 422 with errors.model.

422 Unprocessable Entity

Returned when request validation fails. errors is an object keyed by field name. Common causes:
  • Missing required parameters
  • Invalid parameter values (out of range, wrong type)
  • A value outside the selected model’s info.limits
  • Invalid image/video URL or format
Solution: Iterate the keys of the errors object to identify which fields failed and correct them. Many limits are model-specific — read info.limits from the Model Selection endpoint for the model you are calling.

429 Too Many Requests

Returned when you exceed your rate limit.
Every response carries the current allowance in headers: Solution: Back off and retry — see Limits & Quotas.

500 Internal Server Error

Returned when an unexpected error occurs on our servers.
Solution: Wait a moment and retry your request. If the problem persists, check status.deapi.ai or contact support on Discord.
A job that fails after it was accepted does not produce an HTTP error. The submission returns 200 with a request_id, and the failure surfaces on the job status as status: "error" with error_code, error_message, error_reason, retryable and refunded. See Webhooks for the full value lists.

Best Practices

Handle all error codes

Implement error handling for all possible status codes in your application.

Parse the errors object

For 422 responses, iterate the keys of the errors object to display field-specific messages to users.

Implement retry logic

For 500 errors, implement exponential backoff retry (e.g., 1s, 2s, 4s delays).

Log error responses

Log full error responses for debugging. Include request_id if available.

Example Error Handling