Errors guide

Errors that tell clients what to do next.

Handle stable error codes, request correlation, safe retry decisions, validation details, and idempotency conflicts.

01 / Shape

One envelope across providers.

Every failure uses one normalized envelope regardless of the selected provider. Provider messages are mapped to stable OpenWaya codes so applications do not need provider-specific branches or risk exposing upstream internals.

Error envelope
{
  "contractVersion": "1.0",
  "error": {
    "type": "openwaya_error",
    "code": "model_unavailable",
    "message": "No healthy route is currently available",
    "retryable": true
  },
  "requestId": "req_...",
  "timestamp": "2026-09-05T00:00:00.000Z"
}

02 / Retry

Retry deliberately.

Retry only when both the error and the operation are safe to retry. Use exponential backoff with jitter, respect Retry-After, keep the original idempotency key, and stop before the caller deadline.

  • Retry 429, provider_unavailable, model_unavailable, and request_timeout when marked retryable.
  • Do not retry invalid requests, invalid keys, rejected content, or insufficient balance unchanged.
  • Treat an idempotency conflict as a request-shape bug, not a transient failure.

03 / Support

Correlate without leaking payloads.

Return the request ID when opening a support case. It correlates authentication, configuration, routing attempts, usage, settlement, and safe logs without requiring prompts, model output, credentials, or payment data in support messages.

Build against the contract

Move from guidance to implementation.