> 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-8-channels.md).

# Step 8: Bind a channel

**Step 8 of 10.** Step 7.4 sent you here. The digital employee works conversations on messaging channels, and WhatsApp is the first supported channel. Binding runs through a short lived connection session that keeps the provider authorization exchange auditable and idempotent. Nerova hosts the WhatsApp connection page, so you need no browser component or front-end package.

The [authored source retirement](https://docs.nerovasystems.com/documentation/console/platform-access#campaign-and-escalation-retirement) removes native campaigns and escalation routing. Nerova sends no customer payment messages, so channel readiness has no payment step.

## 8.1 Open a connection session

```bash
curl -X POST https://api.nerovasystems.com/api/v1/tenants/{tenantId}/activation/connection-sessions \
  -H "Authorization: Bearer $NEROVA_API_KEY" \
  -H "Idempotency-Key: 61d02e3f-4a5b-4c6d-8e7f-9a0b1c2d3e4f" \
  -H "Content-Type: application/json" \
  -d '{ "expectedVersion": 4, "channel": "WhatsApp" }'
```

HTTP 201 returns the session:

```json
{
  "sessionId": "pacs_01M0AE5R3K9WQZ7X1C2V4B6N8M",
  "channel": "WhatsApp",
  "expiresAt": "2026-08-04T13:15:00Z",
  "launchUrl": "https://app.nerovasystems.com/connect/...",
  "idempotencyStatus": "Applied"
}
```

The response is abridged. Key fields:

* `launchUrl` is the hosted connection page. It carries the session state, so treat it as a secret and send it only to the merchant.
* `expiresAt`: the session lives for 10 minutes. Complete it before then or open a new one.
* `sessionId` identifies the session in later reads and audit entries.

## Connect a production merchant with the hosted link

The recipe is a server-side call plus a link you send to the merchant.

1. Call `POST /api/v1/tenants/{tenantId}/activation/connection-sessions` as in 8.1, with your Live API key.
2. Read `launchUrl` from the 201 response.
3. Send the link to the merchant (an email, an in-product message, or a button in your own UI that opens it in a new tab).
4. The merchant opens the link and completes the Meta WhatsApp signup on the hosted page. Nerova completes the session for you, so you do not call the `/complete` route in this flow.
5. Poll the [activation manifest](/guides/zero-to-live/step-7-activation.md#71-the-loop-pattern-manifest-version-idempotency) until `channel.status` is `Ready`. Then continue the activation loop.

### Connect from the console

You can also connect a merchant's WhatsApp number yourself, from the console, when you are onboarding the merchant hands-on. Open **Account Channels** > **WhatsApp** (or the **Channels** tab of the account), select **Connect WhatsApp** on the account, and complete the Meta WhatsApp signup in the popup. Nerova binds the number to that account, never to your platform organization, and the account shows as connected once Meta has verified the number. Only an Owner or Admin of your organization can do this. An account that already has a number must disconnect it before another can be connected. WhatsApp Business Accounts in Nerova's own Meta portfolio cannot use the popup; use the manual connection under **Platform Channels** for those.

The link expires 10 minutes after the session is created (`expiresAt` in the response). If the merchant is late, open a new session and send the new link; the old one stops working. Sessions are one time: a session that was already completed cannot be completed again.

For your own test tenant, use a WhatsApp number you control as the business number. Nerova stores hashes of the account and asset references, not the raw values: channel identifiers are treated as sensitive from the moment they enter the platform.

The `@nerova/embed` popup component is a preview that is not yet published to npm. It is not required for this flow; the UI Components gallery lists its status.

## 8.2 Routing and the fail closed rule

Once the tenant is Active, inbound messages on the bound channel route to the digital employee, which acts within the mandate levels from step 7.5. Activating the tenant switches its AI receptionist on; pausing, suspending, or deactivating it switches the receptionist off. You can also flip the same switch from the Agent tab of the tenant in the console. Work above its mandate, outside verified capabilities, or without a proven outcome must remain honestly blocked or unproven, not guessed successful. Persisted attention items let your platform provide human handling; they do not imply an automatic escalation router, email fallback, or owner delivery. The same fail-closed principle from step 6 applies: no proof, no autonomous action. See [Attention and explicit relay](https://github.com/Nerova-Systems/Project-Songbird/tree/main/docs/guides/attention.md) for the distinction between recording a handoff and notifying a recipient.

Channel activity is observable through the tenant's activity ledger with metadata only: message content stays inside the conversation surface, and payloads in the ledger are redacted by default.

## 8.3 If the session fails

* `expectedVersion` stale: re-read the manifest, retry with the current version.
* Session expired: open a new session; the old link is dead.
* Session already completed: sessions are one time; read the manifest to confirm the channel is `Ready`.
* Issuer mismatch: complete sessions with the API key that created them.

## Where you are now

Re-read the actual activation manifest and continue only when its required state is observed. If you arrived from step 7.4, return to [Step 7.5](/guides/zero-to-live/step-7-activation.md#75-set-the-mandate) to finish the loop. If your tenant is already Active, continue to eventing.

Continue to [Step 9: Webhooks today](/guides/zero-to-live/step-9-webhooks.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-8-channels.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.