> 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/zero-to-live/step-7-activation.md).
# Step 7: Run activation
**Step 7 of 10.** Your tenant is connected and its capabilities are verified. Activation is the governed loop that turns that connected tenant into an Active digital employee: you map references, confirm identity, bind a channel, set the mandate, capture consents, preview, and activate. Every transition is recorded and receipted.
**Scope:** Nerova sends no customer payment messages, so activation has no payment step. Activation switches the tenant's AI receptionist on, and it creates the tenant's scheduling profile if none exists. The [local source manifest](https://docs.nerovasystems.com/documentation/console/platform-access#campaign-and-escalation-retirement) describes the fixed campaigns and customer definitions that are retired.
## 7.1 The loop pattern: manifest, version, idempotency
Activation is manifest driven. Do not memorize a fixed order; read the manifest and let it tell you what is possible next.
```bash
curl https://api.nerovasystems.com/api/v1/tenants/{tenantId}/activation/manifest \
-H "Authorization: Bearer $NEROVA_API_KEY"
```
The manifest returns the whole state machine in one document: current state, `version`, prerequisite statuses, available duties and their ceilings, required consents, current `blockingReasons`, and `nextAllowedActions`. After every mutation, re-read it.
Three rules apply to every mutating call in this step:
* Send the current `version` from the manifest as `expectedVersion` in the body. A stale value is rejected; re-read the manifest and retry. Every accepted mutation increments the version.
* Send an `Idempotency-Key` header. Replays return the original result; the response's `idempotencyStatus` tells you whether it was a replay.
* Check `nextAllowedActions` before acting. Calling an action that is not allowed yet returns a problem details response naming the blocker.
```mermaid
flowchart TD
M["GET …/activation/manifest"] --> A{"nextAllowedActions"}
A --> ACT["Perform one step
provisioning · identity · channel ·
mandate · consents · preview · activate"]
ACT -->|"expectedVersion + Idempotency-Key"| OK["Accepted — version increments"]
ACT -->|stale expectedVersion| STALE[Rejected]
STALE --> M
OK --> M
OK -->|state becomes Active| DONE[Active digital employee]
```
## 7.2 Provisioning references
Map Nerova's view of the merchant onto your provider's references. The `providerMerchantReference` and `providerLocationReference` values must be the stable identifiers your Provider API implementation serves (step 3.3).
```bash
curl -X PUT https://api.nerovasystems.com/api/v1/tenants/{tenantId}/activation/provisioning \
-H "Authorization: Bearer $NEROVA_API_KEY" \
-H "Idempotency-Key: 2c1e3d4f-5a6b-4c7d-8e9f-0a1b2c3d4e5f" \
-H "Content-Type: application/json" \
-d '{
"expectedVersion": 0,
"hostMerchantReference": "merchant-42",
"providerMerchantReference": "provider-merchant-42",
"locations": [
{
"hostLocationReference": "location-1",
"providerLocationReference": "provider-location-1"
}
]
}'
```
Returns HTTP 200 with the incremented version. The location mapping is validated later at preview time with a live read against your provider, so a typo here surfaces in step 7.7, not here.
## 7.3 Identity confirmation
Confirm which merchant and locations the activation is for. This is the recorded acknowledgement that a human or system on your side checked the mapping.
```bash
curl -X POST https://api.nerovasystems.com/api/v1/tenants/{tenantId}/activation/identity-confirmations \
-H "Authorization: Bearer $NEROVA_API_KEY" \
-H "Idempotency-Key: 5a9b1c2d-3e4f-4a5b-8c6d-7e8f9a0b1c2d" \
-H "Content-Type: application/json" \
-d '{
"expectedVersion": 1,
"hostMerchantReference": "merchant-42",
"hostLocationReferences": ["location-1"]
}'
```
## 7.4 Bind the channel
The digital employee needs a channel to talk on. Channel binding runs through a hosted connection session; the mechanics are covered in [Step 8: Bind a channel](/guides/zero-to-live/step-8-channels.md). Complete it now as part of the loop, then return here. Re-read the manifest after completion; binding a channel is not proof that every readiness prerequisite is `Ready`.
## 7.5 Set the mandate
The mandate is the merchant's standing instruction for how much autonomy the employee has, duty by duty. Each duty is set to one of four levels: `Never`, `AskFirst`, `DoItTellMe`, `JustDoIt`. The manifest lists each duty's ceiling: the maximum level the platform will accept given what is verified and entitled. Requesting above the ceiling is rejected.
The endpoint is `PUT /api/v1/tenants/{tenantId}/activation/mandate`, with `expectedVersion`, `contractVersion`, and `choices` carrying each `duty` and `requestedLevel`. Set `ClientReplies` and `BookingsAndReschedules`. The `PaymentLinks` and `RefundsAndFeeWaivers` duties remain in the wire vocabulary for compatibility, but their ceiling is `Never`: Nerova does not handle customer payments. Use the manifest rather than a hard-coded version or ceiling.
```bash
curl -X PUT https://api.nerovasystems.com/api/v1/tenants/{tenantId}/activation/mandate \
-H "Authorization: Bearer $NEROVA_API_KEY" \
-H "Idempotency-Key: 9e2d3f4a-5b6c-4d7e-8f9a-0b1c2d3e4f5a" \
-H "Content-Type: application/json" \
-d '{
"expectedVersion": 2,
"contractVersion": "2026-08-04.1",
"choices": [
{ "duty": "ClientReplies", "requestedLevel": "JustDoIt" },
{ "duty": "BookingsAndReschedules", "requestedLevel": "DoItTellMe" }
]
}'
```
## 7.6 Capture consents
The manifest lists the consent requirements and the exact contract version string to echo back. Capture each with the reference of the actor who accepted:
```bash
curl -X PUT https://api.nerovasystems.com/api/v1/tenants/{tenantId}/activation/consents \
-H "Authorization: Bearer $NEROVA_API_KEY" \
-H "Idempotency-Key: c47a5b6c-7d8e-4f9a-8b0c-1d2e3f4a5b6c" \
-H "Content-Type: application/json" \
-d '{
"expectedVersion": 3,
"captures": [
{
"requirement": "DataProcessing",
"version": "2026-08-04.1",
"accepted": true,
"actorReference": "owner@merchant-42.example.com"
},
{
"requirement": "RetentionAcknowledgement",
"version": "2026-08-04.1",
"accepted": true,
"actorReference": "owner@merchant-42.example.com"
}
]
}'
```
## 7.7 Preview
Preview is the dress rehearsal: the platform re-checks every prerequisite, including a live read against your provider to validate the reference mapping from 7.2. Preview takes no request body; it verifies the state the tenant is already in.
```bash
curl -X POST https://api.nerovasystems.com/api/v1/tenants/{tenantId}/activation/preview \
-H "Authorization: Bearer $NEROVA_API_KEY" \
-H "Idempotency-Key: f81c2d3e-4f5a-4b6c-8d7e-9f0a1b2c3d4e"
```
```json
{
"ready": true,
"blockingReasons": [],
"mutated": false,
"noSend": true,
"merchantId": "1539251826400956416",
"version": 6,
"observedAt": "2026-08-04T12:55:02+00:00",
"correlationId": "7d3e1f5a-9b2c-4d6e-8f0a-1b3c5d7e9f0a"
}
```
The full response also carries `providerEvidence` (one entry per live provider read, with the operation, status, and record count) and `channelEvidence` (the channel binding proof, hashes only). `noSend` confirms nothing was sent to anyone during the rehearsal.
If `ready` is false, each entry in `blockingReasons` carries a `category`, a stable `code`, and a human readable `detail`. Branch on the code. A common one: `activation.provider_location_mismatch` means the `providerLocationReference` you provisioned does not match what your provider actually serves. Fix the provisioning references (7.2), re-confirm identity (7.3), and preview again.
## 7.8 Activate
Activation requires a stable `reasonCode` (letters, digits, dots, dashes, underscores) that lands in the audit trail:
```bash
curl -X POST https://api.nerovasystems.com/api/v1/tenants/{tenantId}/activation/activate \
-H "Authorization: Bearer $NEROVA_API_KEY" \
-H "Idempotency-Key: 3b6f4a5b-6c7d-4e8f-9a0b-1c2d3e4f5a6b" \
-H "Content-Type: application/json" \
-d '{ "expectedVersion": 6, "reasonCode": "initial-go-live" }'
```
HTTP 201 returns the activation receipt:
```json
{
"receiptId": "parec_01M0AE9EK2HJH25BXY921T3RND",
"state": "Active",
"employeeStatus": "Active",
"activatedAt": "2026-08-04T12:58:31+00:00",
"activationVersion": 7,
"merchantId": "1539251826400956416",
"mandateContractVersion": "2026-08-04.1",
"consentVersions": ["2026-08-04.1", "2026-08-04.1"],
"providerEvidenceHash": "a3f8c1d94b27e6a5f0b8d2c47e91a3f8",
"channelEvidenceHash": "5e2b9d70c4a1f3865d0e8b2a9c47f15e",
"idempotencyStatus": "Applied",
"correlationId": "b7e2f4a9-1c3d-4e5f-8a9b-0c1d2e3f4a5b"
}
```
The receipt is durable and re-readable at any time:
```bash
curl https://api.nerovasystems.com/api/v1/tenants/{tenantId}/activation/receipts/parec_01M0AE9EK2HJH25BXY921T3RND \
-H "Authorization: Bearer $NEROVA_API_KEY"
```
## Where you are now
The tenant is Active: mandate set, consents recorded, channel bound, receipt in hand. The next step goes deeper on the channel you bound in 7.4 and how conversations route through it.
Continue to [Step 8: Bind a channel](/guides/zero-to-live/step-8-channels.md).
---
# 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/zero-to-live/step-7-activation.md?ask=&goal=
```
`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.