> 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-3-implement-provider-api.md). # Step 3: Implement Provider API v1 Host an implementation of Provider API v1, the single published contract through which Nerova operates a merchant's calendar. {% hint style="info" %} Requires [Step 2: First calls](/guides/zero-to-live/step-2-first-calls.md). {% endhint %} **Step 3 of 10.** You can call Nerova; now Nerova needs something to call. In this step your platform hosts an implementation of Provider API v1, the single published contract through which Nerova operates a merchant's calendar. This is the largest engineering task in the journey and it is entirely inside your own codebase. ## 3.1 Direction: you implement, Nerova calls Integration flows one direction. Your platform exposes an HTTP API that implements this contract against your own system of record, and Nerova is the only caller: ``` Nerova execution plane -> https://your-platform.example.com/{base}/v1/... (your implementation of Provider API v1) | -> your system of record ``` Nerova never connects outbound into your platform's own public API, and whether you have one is irrelevant. You choose the base URL and register it on the provider connection in the console (step 5). The base URL must use HTTPS and must not carry a query string or fragment. ## 3.2 The twelve operations The whole surface is twelve operations. Implement the read operations first; they unlock capability verification (step 6) before you finish the writes. | Operation | Purpose | | -------------------------------------- | ----------------------------------------------------- | | `GET v1/manifest` | Declare contract version, provider name, capabilities | | `GET v1/merchant` | Merchant identity, time zone, currency, locations | | `GET v1/services` | List bookable services | | `GET v1/staff` | List staff and the services each can perform | | `GET v1/schedule` | Staff working intervals inside a window | | `GET v1/availability` | Bookable slots for a service inside a window | | `GET v1/clients` | Look up clients by phone or email | | `GET v1/appointments` | List appointments inside a window | | `GET v1/appointments/{id}` | Read one appointment | | `POST v1/appointments` | Create an appointment (idempotent) | | `POST v1/appointments/{id}/reschedule` | Move an appointment | | `POST v1/appointments/{id}/cancel` | Cancel an appointment | The full per operation reference, including authentication, the `Nerova-Contract-Version` header, the error envelope, and certification requirements, lives in the **Provider API v1** section on [docs.nerovasystems.com](https://docs.nerovasystems.com). Build against that reference; this step covers only how it fits the journey. ## 3.3 Contract rules that matter most * **Manifest is the front door.** `GET v1/manifest` declares which capabilities your implementation supports. Nerova believes the manifest only after verifying it (step 6); undeclared or unverified capabilities are never exercised. Start honest and small: declare only what works. * **Appointment creation is idempotent.** Nerova sends `Idempotency-Key` on `POST v1/appointments`. Your implementation must return the original result for a repeated key, never a duplicate booking. * **Stable references.** Every merchant, location, service, staff member, and appointment needs a reference that never changes. Activation (step 7) maps Nerova's references onto yours and the mapping must hold forever. * **Encoding.** JSON, camelCase fields, UTC ISO 8601 instants, minor unit money. The same conventions you saw on the Tenant API in step 2. ## 3.4 What to have ready before continuing You do not need all twelve operations to proceed; you need your implementation deployed and reachable over HTTPS, its manifest honest, and the read path (`manifest`, `merchant`, `services`, `availability`) working. Nerova also maintains a small reference provider sample that implements the contract with in-memory data. Run it to walk steps 4 through 10 before your own implementation is finished, then repeat them against your real endpoint. ## Where you are now Your platform speaks the contract, or you are deferring that work and using the reference provider sample to learn the rest of the journey first. Either way, the next step creates the tenant that everything else hangs off. Continue to [Step 4: Provision a tenant](/guides/zero-to-live/step-4-provision-tenant.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-3-implement-provider-api.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.