Skip to main content
Errors use a consistent JSON envelope:

​
Error fields

Use the HTTP status and error.type in program logic. Messages can be improved or localized by the service.

​
Status codes

​
Invalid request examples

Common causes of 400 include:
  • Missing model, input, or instruction.
  • Sending both choices and catalog.
  • Sending neither choices nor catalog.
  • Providing fewer than two choices, more than 300 choices, or duplicate choices.
  • Sending an empty string where the schema requires a non-empty string.

​
Authentication errors

Catalog creation, reads, and deletion require a bearer key in the current contract. When a key is missing or invalid, handle 401 as a configuration error rather than retrying the same request.

​
Resource not found

GET /v1/models/{model} returns 404 when the model is not available. Catalog reads and deletes return 404 when the catalog does not exist or is not available to the authenticated account.

​
Debugging a failed request

  1. Save the HTTP status and error.code.
  2. Capture X-Request-ID if the response includes it.
  3. Record the operation and model without logging secrets.
  4. For 400 or 401, fix the request or configuration.
  5. For 429 or 503, apply the retry policy from production checklist.
Do not log bearer tokens or full user input by default. Request IDs are enough for Aspas Labs support to start tracing a call.