Skip to main content
POST
Create a clinical note

Authorizations

Authorization
string
header
required

API key from Developers → API Keys, sent as Authorization: Bearer .

Headers

Idempotency-Key
string

Any unique string (≤255 chars). A retry with the same key within 24 hours replays the original response (Idempotent-Replayed: true) instead of creating a second record.

Maximum string length: 255

Body

application/json
patient_id
integer
required

The patient the note belongs to

form_id
integer
required

An active practitioner/scribe form template of the account to file the note against — list /form_templates to find one

data
object
required

Answers keyed by the form schema's field names (the template's schema lists them). Keys the schema does not define are refused (unknown_field)

appointment_id
integer | null

The documented appointment; must belong to the patient

state
enum<string>
default:final

final stamps finalized_at / finalized_by

Available options:
draft,
final
note_type
enum<string>

Defaults to the form's own type

Available options:
practitioner,
scribe
appt_date
string<date> | null

Date of the documented visit

created_at
string<date-time> | null

Historical-import override, UTC: back-dates the note's created_at/updated_at (and, for a final note, finalized_at) so imports keep their chronology

metadata
object

Integrator-owned key/value metadata (max 50 keys). Values are strings (≤500 chars), numbers or booleans and read back with the type they were written with. On write, a null value removes the key. Filter with metadata[key]=op:value; number operands compare numerically.

Response

The clinical note

data
object

A clinical note in the unified note shape the app itself reads: the raw answers (data, keyed by the form schema's field names), the human-readable rendering (formatted_fields, resolved against the schema snapshot taken when the note was written), and the note's clinical context.