Skip to main content

Error Response Format

Errors return a JSON body with an error object and an HTTP status code:
The type field is the machine-readable discriminator.

Status Codes

SDK Handling

Retry Policy

Retry only transient errors:
  • Retry 429, 500, 502, and 503 with exponential backoff.
  • Do not retry 400 or 401 until you fix the request or key.
  • If a confidential upstream verification fails, treat it as a failed security condition, not a normal retry loop, unless the API response documents it as transient.

Common Cases

Confirm the Authorization: Bearer <API_KEY> header, check for whitespace, and create a fresh key from the Phala dashboard if needed.
List valid model ids with GET /v1/models. Do not assume a model id exists until it appears in the catalog.
A request with provider: {"zdr": true} returns 404 when the selected model has no available zero-data-retention route. Query GET /v1/models?zdr=true before sending sensitive prompts that require this property.
Some models support max_tokens; others require max_completion_tokens. Check supported_parameters in /v1/models.
Back off and retry. For sustained high volume, use dedicated GPU TEE capacity.
Retry after backoff or choose another model. For sensitive prompts, confirm the replacement model returns upstream.verified.result = verified.

Best Practices

  • Branch on HTTP status and error.type, not message text.
  • Keep API keys in environment variables or a secret manager.
  • Never log request bodies for sensitive prompts.
  • Verify x-receipt-id when the response is security-sensitive.