> For the complete documentation index, see [llms.txt](https://docs.nerovasystems.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nerovasystems.com/guides/provision/go-live.md).

# Go-live checklist

Prepare your platform's API integration for Production access. Every item below is proven on your Live key (`nrv_live_`); there is no separate environment to prepare against and nothing to promote.

> **Production is gated.** Live API keys are issued to approved platforms and run on a free testing allowance first. Running real merchants requires billing, provider certification, release proof, and an explicit entitlement — see [Lifecycle and availability](https://docs.nerovasystems.com/documentation/api/lifecycle#current-status). This checklist is how you arrive at that gate ready.

## Prove it on your Live key

An approved platform starts with one Live key and a free testing allowance of 5,000,000 tokens that is never invoiced. Use it to prove every row below with your own test tenants, a test WhatsApp number, and synthetic customers.

If the allowance runs out before a commercial agreement is signed or a card is saved, the key and the AI pause until one of them is in place. Nerova staff mark the agreement signed, or you save a card under **Billing details** in the console. After that, leftover free tokens are used first. With an agreement, each closed billing period produces a monthly invoice payable within 30 days; with a saved card, the card is charged automatically at period close. See [Platform access](https://docs.nerovasystems.com/documentation/console/platform-access#from-approval-to-your-first-invoice).

Only Live keys exist. Any attempt to create a non-Live key returns `403 api_key.sandbox_disabled`.

## 1. Credentials and access

* [ ] API keys are stored in a secret manager, never in code, config files, or logs — you cannot re-read a key after creation.
* [ ] Each backend service uses its own key with the **narrowest scope set** it needs, so a leak has a small blast radius and rotation has a small footprint. See [Authentication](https://docs.nerovasystems.com/documentation/getting-started/authentication#scopes).
* [ ] You have rehearsed key rotation: create replacement, deploy, revoke old key, confirm `401` from the revoked key.
* [ ] Platform accounts: key **tenant grants** are managed deliberately — new tenants are granted to exactly the keys that serve them.

## 2. Provisioning and activation

* [ ] Tenant creation is idempotent end to end: re-running your provisioning job creates zero duplicates ([partner playbook](/guides/provision/partner-playbook.md#1-create-tenants-idempotently)).
* [ ] Your pipeline polls `provisioningState` with bounded backoff and handles `Failed` + `lastErrorCode` by replaying the same command with the same key.
* [ ] Activation is driven from the manifest's `blockingReasons`, never from assumptions about step order.
* [ ] Activation **receipts** are stored against your merchant records for audit.
* [ ] You have tested the repair paths: credential replacement, connection test, `reconcile` after repair, and pause/resume.

## 3. Error handling

* [ ] Problem responses are parsed by `status` + `code`, tolerating unknown fields and non-JSON bodies ([error guide](/guides/build-well/error-handling.md#parse-problems-by-code-not-by-text)).
* [ ] Retries are bounded, jittered, and only applied to `429`/`503`; `400`/`401`/`403`/`404` are never blind-retried.
* [ ] `409`/`412` conflicts re-read state before retrying.
* [ ] Unknown-outcome writes are resolved by read-back and same-key replay — never a fresh key.
* [ ] `X-Request-Id`/`correlationId` is logged on every failure, next to your command id and idempotency key.

## 4. Data handling

* [ ] Provider credentials flow through your systems write-only: submitted to Nerova, never persisted, displayed, or logged on your side. See [Connections](https://docs.nerovasystems.com/documentation/concepts/connections#write-only-credentials).
* [ ] Nothing sensitive rides in `X-Request-Id`, idempotency keys, `externalReference`, or display names.
* [ ] Your integration treats ledgers as metadata and does not expect conversation content — [Security and data ownership](https://docs.nerovasystems.com/documentation/security/data-ownership) explains what you will and will not receive.

## 5. Capability and readiness discipline

* [ ] Your integration checks capability state (`verified` / `unsupported` / `unverified`) instead of assuming features exist — [Capability model](https://docs.nerovasystems.com/documentation/platform/capability-model).
* [ ] Your UX degrades gracefully when a capability is suspended: the platform fails closed, and your surface should explain rather than error.
* [ ] Attention items (`GET …/attention`) reach a human on your side within a defined time.

## 6. Operational readiness

* [ ] Usage (`GET …/usage`) is monitored per tenant, and you know how much of the free testing allowance is left. Allowance usage is never invoiced; do not infer commercial pricing from it.
* [ ] Rate-limit metadata is observed and load is shed *before* `429` at your expected fleet size.
* [ ] If webhooks are enabled for your organization, receivers verify signatures, dedupe on event id, and survive a redrive ([webhooks guide](/guides/build-well/webhooks.md)); otherwise your polling cadence is deliberate, bounded, and sufficient.
* [ ] You know your support path: [support](https://docs.nerovasystems.com/documentation/resources/support), with correlation IDs ready.

## The gate itself

When the checklist holds, Production access is an application, not a self-serve switch. Expect four requirements:

1. **Billing** — a commercial billing relationship must exist for Production use: a signed commercial agreement (monthly invoice, payable within 30 days) or a saved card. Evaluation on the free testing allowance precedes it.
2. **Provider certification** — the provider connections you rely on must be `Certified`, not merely `Unverified`-but-working. Certification is earned by a full conformance run: every published Provider API v1 operation and error path exercised with zero skipped checks, with the run report as the evidence.
3. **Release proof** — evidence your integration behaves correctly on your Live key (this checklist is the shape of that evidence).
4. **Entitlement** — an explicit grant that turns on Production for your organization.

There is no self-serve path today, and no date is promised here — the [changelog](https://docs.nerovasystems.com/changelog) records availability changes. [Contact support](https://docs.nerovasystems.com/documentation/resources/support) when you believe you are ready.

## After the switch

Going live does not change your credentials. The same Live key and the same tenants continue; the difference is that production tenants are activated with real consent, the AI receptionist is switched on at activation, and your usage is billed once the testing allowance is spent.

## Next steps

* Not ready on a row? Each links to its guide — start with the [partner playbook](/guides/provision/partner-playbook.md).
* Availability changes land in the [changelog](https://docs.nerovasystems.com/changelog).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.nerovasystems.com/guides/provision/go-live.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.