# Going live

> A checklist to work through before real users reach your integration, and what to know about the missing sandbox.

Source: https://docs.voice.kheelona.com/guides/going-live/

There is **no separate sandbox or test mode**. You integrate against the live service. The first launch is limited and
partners are hand-picked, so Kheelona may add a test mode later. Until then, build carefully, and expect your tests to
use real sessions.

Every session counts against your account: it takes one of your concurrent places and its minutes are counted. Test within
your **session limit**. Ask the Kheelona team what your limits are: the maximum number of sessions at once, the
longest session and, if one is set, a monthly allowance. See [Limits](https://docs.voice.kheelona.com/concepts/limits.md).

Kheelona is **best effort during the partner pilot**, and planned maintenance is announced in advance. Your product should
cope with a refused session, a busy answer and a dropped connection.

## Checklist

**Keys and secrets**

- [ ] The API key is only on your server, in a secret store, and in no repository, page, app or log.
- [ ] Your mint route authenticates the user before it creates a session.
- [ ] You know how to rotate a key, and you have done it once.

**Browsers**

- [ ] Your production page is on `https`, and its origin is in **Allowed origins**.
- [ ] You asked Kheelona to turn **development access** off, and the page still works.
- [ ] Your page has a strict Content Security Policy. See [Security](https://docs.voice.kheelona.com/guides/security.md).
- [ ] The microphone is requested from a click, and the page explains what to do when it is denied.
- [ ] "Tap to allow sound" is handled with `resumeAudio()`.
- [ ] You tested on the browsers and phones your users have, on a mobile network too, which may use the WebSocket
  fallback.

**Errors and limits**

- [ ] You handle every code in [Errors and retries](https://docs.voice.kheelona.com/guides/errors-and-retries.md), and you retry only what is retryable,
  with a new session after a failed connect.
- [ ] When Kheelona is busy, your product says so kindly and tries again after the wait.
- [ ] When the session is about to end (the `warning` event), your product can say goodbye or start a new session.
- [ ] You keep the `request_id` of every HTTP error, and the session ID with the code of every `error` event, so we can find it.

**Users and privacy**

- [ ] `end_user_ref` is an opaque ID of yours, and `metadata` holds no personal data.
- [ ] `instructions` holds only what the voice needs.
- [ ] You have the consent you need from your users, including a parent's approval for children, and you tell them that
  conversations are handled by AI services. See the [data and privacy policy](https://docs.voice.kheelona.com/policies/data-and-privacy.md).
- [ ] You know what you do with captions and transcripts: Kheelona does not keep them.
- [ ] If you use the `safety` event for safeguarding, someone is responsible for reading it.

**The conversation**

- [ ] You tried every language you declare. Beta and alpha languages are marked, so test them with care.
- [ ] You chose `interruptions` for your devices. See [Interruptions and echo](https://docs.voice.kheelona.com/guides/interruptions-and-echo.md).
- [ ] A long silence and the time limit end a session cleanly in your product.

## Then

Start small. Let a few real users in, watch the **Connection log** and **Usage** pages of your console and your own logs, then widen.