> ## Documentation Index > Fetch the complete documentation index at: https://docs.pyai.com/llms.txt > Use this file to discover all available pages before exploring further. # Production readiness > Move from a PyAI sandbox key to production with the current region, language, billing, reconnect, retention, limits, and reliability contracts. 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: ```bash theme={null} curl https://api.pyai.com/v1/me \ -H "Authorization: Bearer $PYAI_API_KEY" ``` 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](/reference/reliability). ## 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](/reference/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](/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](https://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. Stable codes, retries, idempotency, and key-specific limits. Retention, tenancy, and data-use boundaries. Serving status and fallback behavior by product. Region, latency, reconnect, status, and SLA posture.