> 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/documentation/core-concepts/integration-topology.md).

# How integration works

Nerova is API-first SaaS. Your platform team builds the API integration and owns the mapping to its business data. Use the documented APIs, SDKs, and webhooks; keep machine credentials and receptionist operations out of business-user browsers. Nerova does not undertake bespoke integration work against each platform's API.

The [first-release scope](/documentation/console/platform-access.md#first-release-scope) covers only Platform accounts serving human medical/clinic, salon/barber, and beauty businesses including nails. This topology is not an any-industry offer or a customer WhatsApp payment integration.

The diagram shows your backend's API access, not a decision about future integration transport. Technical request/response specifications belong in the API reference; they are not a separate product category.

```
Business user -> Host UI -> Host backend -> Nerova API
                                |
                                -> Host platform system of record
```

## Credential topologies

| Topology      | Provider connection                                     | Nerova API-key target                             |
| ------------- | ------------------------------------------------------- | ------------------------------------------------- |
| Single tenant | One isolated credential per integration tenant          | Exactly one integration tenant                    |
| Multi tenant  | One connection may serve many mapped downstream tenants | A non-empty explicit integration-tenant grant set |

A software platform may provision one or many single-tenant connections; serving one tenant is the same Platform account model with a single tenant. A multi-tenant account receives no implicit whole-account access: each key lists the tenants it can operate.

## Responsibilities

| Component                   | Owner                                | Responsibility                                                                                         |
| --------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------ |
| Host UI                     | Platform                             | Authentication, business-facing setup, and operations                                                  |
| Host backend                | Platform                             | API integration, API-key storage, authorization, API calls, and reconciliation                         |
| Account control plane       | Nerova                               | Human membership, integration tenants, topology, API-key grants, and billing                           |
| Main execution plane        | Nerova                               | Canonical provider connections/bindings, provider-neutral operations, receipts, autonomy, and channels |
| Historical Test environment | Nerova                               | Retired; Test keys are no longer issued. Legacy fixture behavior is documented for reference only      |
| Production API              | Nerova                               | Access is gated by billing, certification, and entitlement                                             |
| Business records            | The host platform's system of record | Authoritative services, clients, schedules, and appointments; the platform owns their integration      |

The browser never receives a Nerova API key. Behind the single machine host, a Live key is served only by Production. Test keys are no longer issued. Console sessions are browser-only: signing in to the console never authenticates a request against the machine host.

## WhatsApp channel roles

Provider credentials and WhatsApp channels are separate connections.

| Role                      | Owner             | Audience                                                         |
| ------------------------- | ----------------- | ---------------------------------------------------------------- |
| Customer booking          | Downstream tenant | Customers booking with the receptionist                          |
| Platform business console | Partner           | Verified owners and staff of explicitly bound downstream tenants |

Inbound routing resolves the recipient endpoint, channel role, and explicit tenant binding before receptionist work begins. A partner console may bind to several downstream tenants, but every tenant grant remains explicit.

## Recommended sequence

1. Read [Platform access](/documentation/console/platform-access.md): the target is platform approval, then private docs and credit-funded Testing before a commercial agreement.
2. Complete the supported first calls in the [Quickstart](/documentation/get-started/quickstart.md). Every call uses your Live key, which runs on the free testing allowance.
3. Model your merchants with [accounts and tenants](/documentation/core-concepts/accounts-and-tenants.md), then attach [provider connections](/documentation/core-concepts/connections.md).
4. Integrate supported reads, then writes with a stable `Idempotency-Key` and read-back handling.
5. Complete the required release evidence and Production access gates. Testing allowance does not itself authorize Production use.

Webhooks are optional in this sequence: polling covers the same state transitions, and you can add [webhook subscriptions](https://docs.nerovasystems.com/guides/webhooks) as a latency optimization once the integration works.


---

# 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/documentation/core-concepts/integration-topology.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.