> ## Documentation Index
> Fetch the complete documentation index at: https://build.practicehub.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> The PracticeHub API — one API for integrations, automations and AI agents

PracticeHub is a practice management platform for healthcare clinics. The PracticeHub API is the single, canonical way to work with an account's data from outside the app: a REST API for integrations and automations, and an MCP server so AI assistants can act inside a clinic on a team member's behalf.

<CardGroup cols={2}>
  <Card title="REST API" icon="square-terminal" href="/quickstart">
    Patients, appointments, practitioners, locations, invoices, payments, files and more — read, filter, create, update, delete.
  </Card>

  <Card title="MCP Server" icon="microchip" href="/mcp/overview">
    Connect Claude, ChatGPT or your own agent. Same data, same rules, discovered automatically.
  </Card>
</CardGroup>

## How it is put together

* **One account, one tenant.** Every clinic has its own subdomain and its own isolated database. Your base URL is `https://{clinic}.{region}.practicehub.io/v3/api` — the host the practice signs in on (the region host is the one in the practice's login URL — `neptune` (London), `mercury` (Frankfurt), `vulcan` (Ohio), `jupiter` (Singapore) or `apollo` (Sydney)) — and a credential only ever reaches the account it was created on.
* **Resources, not endpoints.** Each resource (`patients`, `appointments`, …) is a uniform collection: list with filters, fetch one, create, update, delete. `GET /schema` tells you exactly what every resource exposes and accepts.
* **The app's rules apply.** Writes go through the same services PracticeHub itself uses — a booking checks the patient is active and the resource is at that location, a payment updates the balance, voiding an invoice releases its allocations. You get field-level validation and meaningful status codes instead of surprises.
* **Your data on our records.** Every record carries a `metadata` object for your own identifiers, which you can filter on.
* **Push, not poll — coming soon.** [Webhooks](/guides/webhooks) will tell you when records change — whether the change came through the API, from staff in the app, or from a background job — with thin, signed payloads.
* **Built to be discovered.** The OpenAPI reference on this site is generated from the running API, and the MCP server exposes the same model to AI clients.

## Where to next

<Steps>
  <Step title="Authenticate">
    Create an API key and make your first call — [Authentication](/authentication).
  </Step>

  <Step title="Query">
    Filters, sorting, pagination and discovery — [Querying](/guides/querying).
  </Step>

  <Step title="Write">
    Creating and changing records safely — [Writing](/guides/writing).
  </Step>

  <Step title="Build">
    Complete worked integrations — a [booking widget](/examples/booking-widget), a [CRM sync](/examples/crm-sync), an [accounting export](/examples/accounting-export), a [webhook receiver](/examples/webhook-receiver) — and the [best practices](/guides/best-practices) they follow. Stuck? [FAQ](/faq).
  </Step>
</Steps>

<Note>
  Coming from the legacy `/api`? [Why the new API](/why-the-new-api) walks through every difference and the reasoning; [Migrating from the legacy API](/guides/migrating-from-legacy) has the before/after tables. Attribute names and filter syntax are unchanged, so most integrations move in an afternoon.
</Note>