Documentation / API reference
REST API reference
This is the detailed reference beneath the API overview page: exactly how bearer-token authentication works, the request and response shape for patients and appointments, and the error codes an endpoint returns.
Which plan this needs
Connecting a third-party client (OAuth and the MCP server) needs the Complete plan, which includes the 30-day trial. The gate is on third-party access, not on the API itself: the dashboard calls these same REST endpoints with a signed-in session on every plan. A client registers itself through OAuth dynamic client registration, and a signed-in member of a practice on Complete approves it. Connected apps are listed, and can be disconnected, under Settings, then Account. The pricing page lists every band.
How to use this reference
All endpoints are rooted at /api/v1. Most require Authorization: Bearer <token>. The ones that do not are the public booking and form endpoints, the OAuth endpoints, the password-reset and sign-in-link requests, the invitation and OAuth authorize lookups, the public contact and referral endpoints, and openapi.json itself; the specification marks each of them as carrying no security, which is the list to trust. Successful responses share one envelope with a data field and a requestId; errors share the mirror shape with a code, a display message, and optional details. The four pages below cover, in order: how the bearer token itself works, the patients resource, the appointments resource, and the full error code table.
What this reference does not cover
Billing, forms, files, tags, search, reporting, staff and invitations, chairs and services, the dental chart and perio exams, notifications, the audit log, calendar sync and patient imports are all part of the API, and per-field pages for them are still to come. Every one of them is already in the machine-readable OpenAPI document at /api/v1/openapi.json, which covers every REST integration endpoint rather than just the four resources written up here. MCP is described separately, under its own pages, because it speaks JSON-RPC rather than REST. The website builder, phone line, passkey and in-app assistant routes are dashboard-only and are not in it. There is no official client SDK yet.
Reference pages
Authentication
Bearer tokens, Firebase ID tokens vs. OAuth access tokens, and the auth error codes.
Patients
The patient and patient-note object shapes, the core endpoints, and their request and response fields.
Appointments
The appointment object, overlap/double-booking rules, and the availability endpoint.
Errors
The full error code table, the success and error envelope shapes, and request-id correlation.
Common questions
HyperCRM is paid software. Every practice starts with a 30-day free trial of the Complete plan, with no card needed. After that, Essential starts at €19 a month and Complete at €34, VAT included. The price depends on how many practitioners you have. Every price is on the pricing page, so you never need a sales call.
Patient records are encrypted, both where they are stored and on their way to your screen. Files are private, and a link to one stops working after a short time. Changes to patient records are recorded, with who made them and when. There is no shared practice password: everyone has their own account. On the Complete plan, the practice owner can also require two-step sign-in for the whole team.
The overview page at /developers/api is a readable summary meant to be read once. This hub and its four detail pages are reference material: exact field names, required and optional parameters, status codes and error codes, for looking one thing up while you are writing against it.
Yes. An OpenAPI 3.1 document is served at /api/v1/openapi.json, covering every REST integration endpoint, not just the resources written up here. MCP is not in it: it speaks JSON-RPC, and its contract is the tool registry instead. Dashboard-only routes are excluded. It is generated from the same validation schemas the server enforces, so the spec's request shapes are the ones the server accepts, and a test fails our build if the two drift.