---
title: "REST API reference - HyperCRM developers"
description: "HyperCRM's REST API in plain terms: bearer-token auth, the resources that exist today, pagination, and the shared JSON envelope every endpoint uses."
canonical: "https://hypercrm.app/developers/api"
lang: "en"
updated: "2026-07-25"
---

_Developers / API_

# The same API the app calls

HyperCRM's REST API is a JSON-only interface, scoped to your practice and authenticated with a bearer token. It is the same layer the web app uses internally, not a stripped-down copy, covering patients, scheduling, billing, forms, files, tags, search and reporting.

[Start the free trial](/dashboard) · [Read the API reference](/docs/api)

## Resource families

### Patients & notes

Create, update and search patient records, with tag toggling and revision-tracked clinical notes.

### Scheduling

Appointments, chair-blocking entries, and a derived availability endpoint for a chair on a given day.

### Billing

A service catalogue, per-patient charges/credits/receipts, and a computed invoice view with tax.

### Forms & files

A dynamic form builder with shareable public links, and private file storage served via signed URLs.

## Which plan this needs

The REST API and the MCP server are included on the **Complete** plan and are not available on Essential — integrations are a larger-practice need and a real support burden, so they sit on the plan that pays for them. The [pricing page](/pricing) lists every band. OAuth clients are created from practice settings once you are on Complete.

## Authentication

Every endpoint requires `Authorization: Bearer <token>`. The token is normally a Firebase ID token from a signed-in HyperCRM session; there is no separate signup step — your user, practice and membership are found or created on first successful verification. OAuth clients (see the [MCP page](/developers/mcp)) can use an opaque access token instead, and both forms work interchangeably wherever a bearer token is accepted.

## What's there

Patients and patient notes, tags, appointments and chair availability, the service catalogue and per-patient billing with a computed invoice view, a form builder with public shareable links, private file storage served through short-lived signed URLs, cross-practice search over patients and appointments, dashboard KPIs and owner-only reports, and staff/invitation management. Every practice also carries a `packId` (generic or dental today), and pack-specific values like patient status options come back from a bootstrap endpoint rather than being hardcoded in the API.

## Requests and responses

Successful responses share one envelope: a `data` field holding the resource, and a `requestId` you can use for support correlation. Errors share the mirror shape — a stable `code`, a safe display `message`, and optional `details` for field-level validation issues. List endpoints such as patients accept `limit` and `offset`; out-of-range values are clamped rather than rejected, and the response echoes back the values actually used.

## What to expect from it

The API is the one the product itself calls, so it moves with the product rather than lagging behind it. There is no official client SDK and no webhook system. Rate limits are published: every operation in the OpenAPI document states the policy that governs it. The full reference — every endpoint, its fields, and the errors it returns — is at [API reference](/docs/api).

## Common questions

### How much does HyperCRM cost?

HyperCRM is paid software. Every practice starts with a 30-day free trial of the full Complete plan, with no card required. After that, plans start at €19 and €29 a month excluding VAT, banded by how many practitioners you have. Every price is printed on the pricing page rather than quoted on a call.

### How is patient data protected?

Patient records are encrypted in transit and at rest, files are stored privately and served through short-lived signed links, and every change is written to an audit log. Staff accounts sign in with passkeys rather than shared passwords.

### What does authentication actually look like?

Every call sends `Authorization: Bearer <token>`, normally a Firebase ID token from a signed-in session, verified server-side on each request. There is no separate API-key step: your practice and membership are resolved from that same token, and access is always scoped to your own practice's data.

### Are there published rate limits?

Yes. Every endpoint is rate limited, and each operation in the OpenAPI document at `/api/v1/openapi.json` states the limit that applies to it. Every response also carries your remaining budget in the `RateLimit-Limit`, `RateLimit-Remaining` and `RateLimit-Reset` headers, so a client can back off before it is throttled rather than after. A throttled request returns `429` with `rate_limit_exceeded` and a `Retry-After` header.

## Build against the same data the app uses

A bearer token against your own practice's data, on the trial. No card to start.

[Start the free trial](/dashboard)