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 models or 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.