Prior authorization, as an API
One JSON request in. Completeness checked against the payer’s own criteria, their form filled, the FHIR bundle assembled, the submission tracked to a decision. You keep the provider relationship, the UI and the data.
No BAA, no contract, no card. The key is issued the moment you ask for it.
{
"profile": "aba.v1",
"partner_reference": "clinic-4417/auth-9",
"payer": { "name": "Aetna Better Health of New Jersey" },
"period": { "from": "2026-09-01", "to": "2027-03-01" },
"requested_hours_per_week": 25,
"service_codes": [
{ "cpt": "97153", "description": "Adaptive behavior treatment by protocol", "units_per_period": 2600 },
{ "cpt": "97155", "description": "Adaptive behavior treatment with protocol modification", "units_per_period": 208 }
],
"client": {
"name": "Sam Doe",
"dob": "2020-03-15",
"sex": "male",
"state": "NJ",
"diagnosis_icd10": "F84.0",
"service_delivery_setting": "home"
},
"enrollment": {
"member_id": "W248166043",
"group_number": null,
"subscriber_name": "Alex Doe",
"subscriber_relationship": "parent"
},
"organization": {
"name": "Northwind Behavioral Health",
"npi": "1548392017",
"tax_id": "82-4419907",
"phone": "609-555-0142",
"fax": "609-555-0143",
"address": { "street": "18 Mercer St", "city": "Princeton", "state": "NJ", "zip": "08540" }
},
"clinician": {
"name": "Lisa Provider",
"npi": "1932847561",
"credential": "BCBA",
"license": "35BX00123400",
"license_state": "NJ"
},
"clinical": {
"treatment_plan_date": "2026-08-14",
"diagnosing_provider_name": "Dr. Eval Provider",
"narrative": "The client demonstrates significant deficits across…"
}
}Returnsevery missing or malformed field, coded, before a payer ever sees it.
What is actually live, today
5
endpoints live in production
4
endpoints sandbox-only, pending a payer connection
0
live payer transactions carried to date
22
payer forms mapped and golden-file tested
The rail has not yet carried a production payer submission. Validation, form-fill and bundle assembly are real and useful today and need no payer connection; submission, CRD, DTR and status run against a mock payer until the first connection completes. You would establish this in the first call anyway.
Nine endpoints implemented, eight more specified. Lead with the facade, drop to the primitives when you need them — everything is callable on its own. Full detail in the API reference.
| Endpoint | Does | Status |
|---|---|---|
/v1/sandbox/signup POST | Issue a sandbox key Name and email in, a working API key out, immediately. No BAA, no contract, no card, no approval step. The key is returned exactly once — only its SHA-256 is stored, so a lost key means a new signup. | live |
/health GET | Liveness and build version Unauthenticated. Returns the running core version and uptime. Poll it from your own monitoring — it is the same check our deploy gate uses. | live |
/v1/prior-auth/validate POST | Check a request before anyone sees it Parses and validates the request against PriorAuthRequestV1 and returns the normalised value, or every failing field path with its message. No payer contact, no submission, no liability — this is the endpoint to call on every keystroke-settled form, not just before submitting. | live |
/v1/prior-auth/official-form POST | Fill the payer’s own PDF Selects the form mapper from payer.name plus client.state, fills the payer’s real authorization form, and returns the PDF bytes. 22 payer forms are mapped today, each covered by a golden-file test. Needs no payer connection — the form is a document, not a transaction. | live |
/v1/prior-auth/bundle POST | Build the FHIR bundle, don’t send it Returns the Da Vinci PAS request bundle we would transmit — assembled, normalised, ready for your own connection to carry. This is the bring-your-own-rail product: you keep the payer relationship and the submission liability, we do the assembly. Pure and side-effect free; it never resolves a channel or touches payer config. | live |
/v1/prior-auth/submit POST | Submit the authorization Resolves the channel for this payer and state, then submits. Requires an Idempotency-Key: the same key with the same body replays the stored response rather than submitting twice; the same key with a different body is a client bug and returns 409 rather than silently overwriting. | sandbox |
/v1/prior-auth/inquire POST | Where did it get to? Retrieves a decision for a prior submission, including asynchronous ones a payer pended. Read-only, so no Idempotency-Key. Pass `trace_number` alongside the request body when you have one. When the resolved channel cannot inquire, you get a well-formed not_capable answer rather than an error. | sandbox |
/v1/prior-auth/crd POST | What does this payer require? Coverage Requirements Discovery: whether prior authorization is needed for these codes under this coverage, and what documentation the payer wants. Always answers 200 — a payer that has no CRD service is a legitimate answer about capability, not a request error. | sandbox |
/v1/prior-auth/dtr POST | Fetch and prefill the questionnaire Documentation Templates and Rules: pulls the payer’s questionnaire for the canonical URLs a prior CRD response named, and pre-populates every answer derivable from the request you already sent. Pass those canonicals as `questionnaire_canonicals` — it is DTR-specific and deliberately outside the contract schema. | sandbox |
22 payer forms mapped field-by-field, each covered by a golden-file test. The set is Medicaid-MCO heavy by design — that is where the authorization burden actually falls.
A payer you need that is not on this list is a form spec and a golden-file test, not a release. Scale and Embedded include an annual allowance; beyond it, they are priced per payer and quoted before work starts.
Stateless by default
We accept the request, build the bundle, submit, return the result — and persist no clinical payload. What is stored is metadata: partner, payer slug, a SHA-256 of the request, timestamps, status, trace number, error codes. None of it is PHI.
Retention is opt-in per request, priced separately, and moves you to a stricter BAA tier. Most partners never need it.
Where we are, stated plainly
If your vendor-management team needs the long version, ask — the security questionnaire gets a real answer, including where the answer is “not yet.”
Nobody in this category publishes. You cannot ask sales what it costs on a Saturday, so here it is. One authorization case covers CRD, DTR, the filled form, 180 days of status, and one resubmission within 90 days.
Sandbox
liveFree
Evaluating the contract on a Saturday, without talking to anyone.
Build
soon$250/ mo · minimum spend
A billing service or RCM firm carrying 5–30 clinics.
Scale
soon$2,500/ mo · platform fee
A small EHR or a large billing group.
Embedded
soon$7,500/ mo · platform fee
A platform putting the rail behind its own UI for its whole book.
| Per year | 1–500 | 501–2,500 | 2,501–10,000 | 10,001–50,000 | 50,000+ |
|---|---|---|---|---|---|
| Authorization case | $12.00 | $9.00 | $6.00 | $4.50 | $3.25 |
| Case, bring-your-own-rail | $7.20 | $5.40 | $3.60 | $2.70 | $1.95 |
| Validation only | $0.60 | $0.40 | $0.25 | $0.15 | $0.12 |
| Form fill only | $2.50 | $1.75 | $1.20 | $0.90 | $0.70 |
Bands are on annual case volume and are applied retroactively at true-up — growing mid-year never costs you the better rate. We do not bill failed calls on our side, and a retry under the same idempotency key is never a second charge.
Synthetic data, a mock payer, and the full v1 contract. No BAA, no contract, no card, and nobody will call you.
Get a key →