v1
latestOpenAPI 3.1.02026-07-2218105157.9 KBCreate a prior authorization
Create a new prior authorization. Provide exactly one of patient_id (existing id) or patient_data (inline demographics; server find-or-creates). Optionally provide one of payor_id or payor_data. New authorizations start in status=pending.
Request body
Authorization type.
Existing patient id. When provided, the patient is looked up by id (must belong to your company and be active). Mutually exclusive with patient_data.
Existing patient-payor id (must belong to the resolved patient and be active). Mutually exclusive with payor_data. Write-only resolution input — this id is used to derive and freeze the member id + insurance id onto the authorization at create time. It is NOT returned on the resource. To read payor information, use payor_member_id, payor_insurance_id, and payor_insurance on the response.
Credentialing record id for the provider requesting the authorization.
Credentialing record id for the servicing provider. Omit when the servicing provider is the same as the requesting provider.
Company-location id where services will be rendered.
Business entity (organization) this authorization belongs to. Optional.
Free-text notes attached to the authorization. Editable post-creation.
Date this authorization should be submitted (YYYY-MM-DD). When set in the future, the request is held out of the active review queue until that date. Omit or send null to submit whenever it is picked up.
When set, the new authorization is seeded with copies of the attached documents from this existing authorization (which must belong to your company). Each document is re-linked as a new file record pointing at the same stored object — the source authorization keeps its own copies. Used to duplicate an authorization (e.g. an assessment into a treatment).
Example request
{
"patient_data": {
"first_name": "Jane",
"last_name": "Doe",
"date_of_birth": "1990-01-01"
},
"payor_data": {
"member_id": "ABC123456",
"insurance_display_name": "Carolina Complete"
},
"service": {
"service_type_codes": [
"AS"
],
"start_date": "2025-01-01",
"end_date": "2025-12-31",
"cpt_codes": [
{
"code": "97153",
"units": "160"
}
],
"requested_visits": 20,
"requested_weeks": 8,
"locations": [
"office",
"home"
]
},
"scheduled_submission_date": "2025-02-01"
}Response
Successful Response
Authorization type.
Lifecycle state of a prior authorization.
Payor outcome on a decided authorization.
Appeal lifecycle. Applies only when decision is denied or partially_approved.
NULL is meaningful: it means no appeal decision has been made yet — the caller hasn't yet asked for one. Setting any value below is an explicit commitment that someone is (or isn't) pursuing the appeal:
requested — operator/patient asked for an appeal; team hasn't started. appealing — team is actively working the appeal. appeal_approved — terminal, won. appeal_denied — terminal, lost. not_appealing — terminal, operator decided not to pursue.
Rationale captured when an appeal was requested. Null when no appeal has been requested.
Appeal case/reference number issued by the payor. Null until the payor assigns one.
Patient this authorization belongs to; use it to open the patient record. Demographics submitted on this PA are the frozen patient_* fields below.
Patient first name as submitted on this authorization. Frozen at create time — not updated when the patient record changes.
Patient last name as submitted on this authorization. Frozen at create time.
Patient date of birth (YYYY-MM-DD) as submitted on this authorization. Frozen at create time.
Member id as submitted on this authorization. Frozen at create time.
Insurance partner id (from the insurances catalog) as submitted on this authorization. Frozen at create time.
Plan display name for this PA's payor, frozen at create time. Null ⇒ display the insurance's canonical name.
Credentialing-record id of the requesting provider. Always present unless the provider record was later removed (FK is ON DELETE SET NULL).
Credentialing-record id of the servicing provider. Null when the servicing provider is the same as the requesting provider or unset.
Company-location id where services are rendered. Null when unset.
Business entity (organization) this authorization belongs to. Null when unset.
Number of attached files. Always present (a cheap aggregate); independent of expand.
When the appeal was submitted to the payor; set when the appeal first becomes active. Null when no appeal has been submitted.
Last time staff followed up with the payor on this authorization's status. Null until the first follow-up.
Date this authorization should be submitted to the payor. When set in the future, the request is held out of the active review queue until that date. Null when no scheduled date is set.
True when the clinic has marked this authorization done (it leaves the default list). Derived from completed_at.
When the authorization was marked done. Null while outstanding.
Id of the user who marked it done. Null while outstanding.
Why a prior authorization was cancelled — captured on every transition into cancelled. other is the escape hatch (the free-text detail then lives in cancellation_note).
Keep the members in sync with the Prisma enum PriorAuthorizationCancellationReason (apps/frontend/prisma/schema/enums.prisma) and the frontend label map PRIOR_AUTH_CANCELLATION_REASON_LABELS. verify-enum-sync only compares UPPERCASE Python members, so — like PriorAuthorizationStatusEnum — this lowercase enum is NOT covered by that check; sync it by hand.
Free-text detail captured with the cancellation reason. Null when none was provided.
When the authorization was cancelled. Null unless the authorization is cancelled.
Example response
{
"appeal_availability": [
{
"day": "monday",
"start": "15:00",
"end": "17:00"
}
]
}