Skip to content
API Reference

Errors

Clipia API's unified error format, the table of HTTP statuses and errorCodes, and which ones are safe to retry.

Every error is returned in a single JSON shape with type, code, and a human-readable message. The HTTP status sets the error class, while the machine-readable code gives the exact reason. Only transient errors (429, 503) are safe to retry with backoff; request errors (4xx) will return the same result unless you change the request.

One unified format

Every error response shares the same shape: an error object with type, code, and message. Branch your logic on the machine-readable code, and use the HTTP status as the error class.

{
  "error": {
    "type": "invalid_request_error",
    "code": "insufficient_credits",
    "message": "Not enough credits for this generation. Please top up your balance."
  }
}

Error codes

HTTPcodeWhenRetry-able
400invalid_requestInvalid body or parametersNo
401invalid_api_keyKey missing, invalid, or revokedNo
402insufficient_creditsNot enough credits on the balanceNo — top up first
403insufficient_scopeThe key lacks the required scopeNo
404not_foundUnknown request_id or modelNo
409idempotency_key_reuseSame Idempotency-Key with different parametersNo — use a new key
409request_in_progressRetry while the first request is still processingYes — after the first finishes
422model_input_invalidParameters don't fit the modelNo — fix the input
429rate_limit_exceededRate limit exceededYes — after Retry-After
500internal_errorInternal errorYes — with backoff
503service_unavailableTemporarily unavailableYes — with backoff

What to retry

It is safe to retry 429, 500, and 503 with exponential backoff. For 4xx request errors (except request_in_progress), retrying unchanged returns the same error — fix the request first.

Messages are sanitised

The message field never exposes internal infrastructure details. Branch on the machine-readable code, not on the message text, which may change.

On this page