Skip to main content
Use this checklist before sending customer traffic. Sandbox and live keys call the same API and models, but production adds billing, capacity, data-location, and recovery decisions that a local prototype does not prove.

​
1. Inspect the live key

Create a pyai_live_ key in the console with only the scopes your application needs, then inspect the exact policy applied to it:
Check:
  • environment is live.
  • scopes contains every endpoint you will call.
  • limits.rps, limits.burst, and limits.concurrency cover expected load.
  • The credit and per-key budget posture is ready for traffic.
Fresh live organizations can return 402 credit_exhausted until funding or graduated signup credit is available. Sandbox keys skip this gate and therefore do not prove live billing readiness. Do not retry a 402; fix the underlying credit, budget, or quota condition.

​
2. Confirm region and latency

PyAI currently serves from one US region. There is no India or APAC data-residency option today. Put your media server, framework worker, or backend near the PyAI region when latency matters, and measure the complete path from your deployment rather than reusing an in-region benchmark. If a single US processing region does not satisfy your residency or continuity requirements, stop before production and confirm an enterprise plan or roadmap fit. See Reliability, latency and regions.

​
3. Confirm language behavior

Language support differs by product:
  • Hear transcription is English-only. Send language=en or omit it. Any other Hear language value returns 400 unsupported_language.
  • Omni currently serves English, French, Spanish, and Hindi. German configuration is accepted but falls back to English; inspect configured.language_active and configured.language_fallback.
  • Speak language availability depends on the selected voice and delivery mode.
Do not infer language from a voice suffix. Indian-English voices speak English; they are not Hindi voices. See Language support.

​
4. Design reconnect and idempotency

Realtime sockets do not resume:
  • A dropped Omni or Hear socket ends that session.
  • Reconnect creates a new session.
  • Re-send Omni configure after reconnect.
  • Keep your correlation id and essential application state in your backend.
Use a new session_label when you need separate call records, or deliberately reuse your own opaque correlation value when your application can distinguish attempts. For REST jobs and durable writes, send the documented Idempotency-Key and reuse it only for the identical logical operation. Honor Retry-After on retryable 429 responses. Never parse human-readable error text; branch on the stable error code or terminal job status.

​
5. Choose the data-retention path

Retention depends on the surface. In particular:
  • Streaming Hear audio is relayed and not written to durable storage.
  • Async Hear URL input is not persisted, but the job and result are retained.
  • Async uploaded audio is retained for up to 7 days; results for up to 30 days.
  • Omni recordings are off by default. When enabled, they are retained for up to 30 days.
  • Omni call records and Recap records are retained for up to 90 days.
Async transcription has no store: false option and its DELETE operation is cancellation, not erasure. Review Security and data before handling sensitive data.

​
6. Exercise failure paths

Before launch, test:
  1. Invalid key: expect 401 unauthorized and stop.
  2. Missing scope: expect 403 forbidden and stop.
  3. Empty live balance or key budget: expect a branchable 402.
  4. Rate or concurrency exhaustion: expect 429 plus Retry-After.
  5. Realtime disconnect: reconnect as a new session and restore application context.
  6. Webhook replay: verify the signature timestamp and deduplicate the event id.
  7. Downstream timeout: prove your application fails safely when a tool, knowledge callback, or CRM destination is unavailable.

​
7. Monitor the production surface

Subscribe to status.pyai.com and record the request, job, call, or session identifier needed for support. Log status codes, stable error codes, retry counts, and latency. Do not log API keys, webhook secrets, raw authorization headers, or sensitive transcript content by default. Operational availability targets are not contractual SLAs. If you require service credits, a data-processing agreement, named subprocessors, zero-retention terms, or a no-training warranty, complete the corresponding enterprise agreement before launch.

Errors and limits

Stable codes, retries, idempotency, and key-specific limits.

Security and data

Retention, tenancy, and data-use boundaries.

Language support

Serving status and fallback behavior by product.

Reliability and regions

Region, latency, reconnect, status, and SLA posture.