What this connects to

Your HR system and your record system by name, what each one can do today, and the calls your engineer would make. Most of the names below say not built, and they are on this page anyway: you finding out from us is better than you finding out after signing something.

What connects today

Working today

Video sessions
Sessions
Run the session in the browser, with each person on their own audio track.
In-person sessions
Sessions
One phone on the table, transcribed and written up the same way.
Record extract
Records
A patient's whole record, emailed to them, with a code a third party can check.

Partly working

HR systems

A sponsoring employer connects one of these so we can answer one question: is this person still one of yours. We never receive a name, a department, a salary or a leaver reason, and there is nowhere in our database to put one.

Workday
Not built
Outbound webhook · steps written
SAP SuccessFactors
Not built
Outbound webhook · steps written
BambooHR
Not built
Outbound webhook · steps written
HiBob
Not built
Outbound webhook · steps written
Personio
Not built
Outbound webhook · steps written
Oracle HCM
Not built
Outbound webhook · steps written
Darwinbox
Not built
Generic webhook
Zoho People
Not built
Generic webhook
Menaitech
Not built
Generic webhook
Rippling
Not built
Generic webhook
Gusto
Not built
Generic webhook
Sage HR
Not built
Generic webhook

The mechanism is an outbound webhook your system calls with a key you mint and can revoke, so a seventh system that is not on this list connects the same way. The steps live in your sponsor console under Integrations.

Record systems

A clinic opens us from a patient's chart and the note a clinician approves files back as a document on that chart. Your system stays the record and ours does not become one.

Epic
Built, no tenant yet
SMART on FHIR R4
Oracle Health (Cerner)
Built, no tenant yet
SMART on FHIR R4
athenahealth
Built, no tenant yet
SMART on FHIR R4
Elation Health
Not built
FHIR R4
Healthie
Not built
FHIR R4
DrChrono
Not built
FHIR R4
Tebra (Kareo)
Not built
Partner API
SimplePractice
Not built
Partner API
TherapyNotes
Not built
Partner API
Valant
Not built
Partner API
Jane
Not built
Partner API
InSync
Not built
Partner API

SMART on FHIR R4 works end to end against a sandbox. No hospital has registered us in its own tenant yet, and each one has to before anything connects there, which is why every row above says built rather than working.

Get started

1Ask us for a partner accountWe open it with you on a call. There is no self-serve key, because a key that can open sessions about real people is not a thing to hand out through a form.
2Mint a key in your consoleShown once. Revoking it stops every call the same second, and the console says when each key was last used.
3Ask somebody for consentThe first call is always the consent call. Everything else returns a refusal until it comes back yes.
4Open a session and send audioYour own reference for the patient identifies them. We never learn who that is.
5Read the draft, approve it as a clinicianA note is a draft until a named clinician approves it, and the name goes on the record.

Authentication

One header. Keys are per partner, minted in your console, shown once, and revocable.

Authorization: Bearer sk_live_...
Content-Type: application/json

A revoked key fails closed on the next call, not at the end of a cache window. Nothing is signed with a shared secret and there is no key in a URL, because a key in a URL is a key in somebody’s log file.

Supported methods

The calls in the order an integration makes them. The full reference, every field and every error, is on the developers page.

POST	/api/partner/v1/consent	Ask a person, and record the answer. Nothing else works until this returns a yes.
POST	/api/partner/v1/sessions	Open a session against your own reference for the patient.
POST	/api/partner/v1/sessions/<ref>/media	Send the audio you recorded, in parts.
GET	/api/partner/v1/sessions/<ref>/transcript	Read the transcript back as it is built.
GET	/api/partner/v1/sessions/<ref>/note	Read the draft note. It is a draft until a clinician approves it.
POST	/api/partner/v1/sessions/<ref>/note	Approve it, as the clinician who is approving it.
GET	/api/partner/v1/subjects/<ref>/readers	Who may read this person's history, and until when.
POST	/api/partner/v1/launch	Open one of our screens inside yours, for one clinician, for one session.

The full reference, with every field and every error

Payload examples

Ask for consent

POST /api/partner/v1/consent
{
  "subjectRef": "your-own-id-for-this-person",
  "scope": "history",
  "askedBy": "dr-nour",
  "channel": "sms"
}

202 Accepted
{ "status": "asked", "askedAt": "2026-03-12T09:04:11Z" }

Open a session

POST /api/partner/v1/sessions
{
  "subjectRef": "your-own-id-for-this-person",
  "clinicianRef": "dr-nour",
  "modality": "in_person",
  "startedAt": "2026-03-12T09:05:00Z"
}

201 Created
{ "ref": "ses_7Kq2", "recording": "awaiting_consent" }

Read the draft note

GET /api/partner/v1/sessions/ses_7Kq2/note

200 OK
{
  "status": "draft",
  "approvedBy": null,
  "soap": { "subjective": "…", "objective": "…", "assessment": "…", "plan": "…" },
  "patientSummary": "…"
}

Refusals look like this, and they are the normal case. A call about somebody who has not said yes returns 403 with { "error": "no_consent" }, not an empty object. Nothing partial comes back.

Use cases

A clinic keeps its own record system

Open us from the chart, record and write the note here, file the approved note back as a document. Your system stays the record.

An employer funds therapy

Your HR system answers one question about one person, on a webhook you can revoke. We never learn who booked anything.

A platform runs its own sessions

Hold the session on your side, send us the audio, get the transcript and the draft note. The clinician who approves it is named.

A telehealth product wants the copilot

Ask about a patient you already hold consent for, and every answer comes back with the sessions it was built from.