Skip to main content
The API is additive within a version: new resources, attributes, event types and optional inputs may appear at any time. While the API is in Beta, details may still be refined — any change that would affect an existing client is announced here first, with a migration window.
​
ISO 8601 dates that say their clock; tags; patient names on appointments; full care plan detail
Changed — every date and time now says which clock it is on by its shape. A UTC stamp ends in Z (created_at: "2026-09-01T14:31:00Z"), clinic wall time carries no zone (starts_at: "2026-09-01T09:00:00"), a calendar day is a plain 2026-09-01. The same shapes are what you send and what you filter with; a zone suffix on wall time is a 422. See Dates, timezones and currency. This replaces the YYYY-MM-DD HH:MM:SS form of the first Beta build.Changed — clinical_notes stamps are created_at / updated_at. A note read carries created_at and updated_at like every other resource (they were created / updated), and the historical-import override on POST /clinical_notes is created_at.Added.
  • tags — the account’s patient tags, read-only (GET /tags, GET /tags/{id}: id, name, color, sort_order).
  • patients.tags[] — the file’s current tags (id, name, color, patient_tag_id, editable, added_at), embedded on every patient read.
  • Accounts on both PracticeHub Classic and 2.0: webhooks and deleted_entities cover changes made in 2.0 only — see the note on Webhooks. Such accounts can now hold PracticeHub API keys and legacy /api keys side by side.
  • patient_tags — put a tag on a file (POST /patient_tags with patient_id and tag_id) or take one off (DELETE /patient_tags/{id}) — write-only, a file’s tags are read on the patient; a tag a care plan put there is editable: false and cannot be removed (409 tag_locked). Both announce patients.updated.
  • appointments.patient — who the visit is for, embedded on every appointment read: id, first_name, last_name, preferred_name and name, the display name as PracticeHub shows it (preferred name over first name, then last name).
  • GET /care_plans/{id} carries the whole plan. A list row still stops at billing, schedules and members; a single read adds each schedule’s phases[] (with the modalities each covers), its appointment_type_ids, auto_sync and sync_status, and its visit tracking; the billing periods[]; the services[] and products[] the plan bundles; and, for a plan with no schedule, plan-level tracking (per billing period or against a visit total). members[] gain id and schedule_override.
​
The PracticeHub API is available in Beta
The PracticeHub API is available in Beta. It is part of PracticeHub 2.0 and, like the 2.0 application itself, carries a Beta label while we refine it with early integrators.What you get:
  • REST API at https://{clinic}.{region}.practicehub.io/v3/api — 26 resources with uniform list / get / create / update / delete, filtering, sorting, cursor pagination, per-record metadata, idempotency keys, and a machine-readable contract (GET /schema, OpenAPI reference, Postman collection).
  • Writes follow the app’s rules. A record created through the API behaves exactly like one created by staff — validation, business rules, balances and the audit trail included.
  • MCP server at /v3/api/mcp for AI assistants (Claude and ChatGPT), read-only for now — OAuth connectors approved by a team member act as that person, with their role’s permissions and their name on the audit trail.
  • Rate limits of 120 requests a minute per account, with AI connectors on a separate budget — see Rate limits.
  • Invoice lines bill the catalogue. Every new line carries a billable_item_id (GET /billable_items).
  • API keys with read/write scopes, expiry, one-click rotation and revocation under Developers → API Keys; every request visible in Developers → API Logs.
  • Webhooks in a limited rollout — patient and appointment events (patients.created/updated/deleted, appointments.created/updated/deleted), thin signed payloads, and a self-serve portal under Developers → Webhooks. Events for further resources are announced here as the rollout expands.
Beta means the contract can still gain polish: we add, and we avoid breaking. If a breaking change is ever necessary, it is announced here with a clear migration window before it takes effect.