Eligibility at booking. One API, no card upload, no three-day wait.
A real-time insurance eligibility API at booking checks coverage the moment a patient picks a payer, shows the copay, and never treats a payer outage as not covered. Commonly cited lift: 2 to 5x.
Eligibility verification at booking
A real-time insurance eligibility API runs eligibility verification at booking from name, date of birth, and payer. The copay estimate API returns an estimated copay in the same response so the patient can book without uploading a card.
Designed to sit inside your booking flow
Your engineers get sandbox keys in week one. The sandbox returns production-shaped payloads, including the ugly cases.
- Soft check from name, DOB, and payer. Member ID optional.
- Estimated copay and deductible status in the response.
- Distinct outage status so a payer outage never reads as "not covered".
- Hosted widget for no-code, REST API and TypeScript and Python clients for everything else.
- Webhooks for re-verification before the visit.
POST /v1/eligibility/soft-check
{
"patient": { "first_name": "Ana", "last_name": "Rivera", "dob": "1988-04-02" },
"payer": "aetna",
"state": "TX",
"service_type": "psychotherapy"
}
200 OK
{
"status": "covered",
"plan": "Aetna Choice POS II",
"network": "in_network",
"estimated_copay": 25,
"deductible_remaining": 0,
"checked_at": "2026-10-05T14:02:11Z"
}Payer outage detection for eligibility
Payer eligibility systems go down. Payer outage detection is how a real-time insurance eligibility API keeps eligibility verification at booking from treating an outage as not covered.
Detect the outage
When a payer's eligibility endpoint errors, times out, or returns a silent bad response, the API emits a distinct outage status. That is not a coverage decision.
Do not convert it to "not covered"
A false negative at booking sends the patient away. The booking flow can let them continue, mark the copay estimate as pending, and re-check before the visit.
Re-check before the visit
Queue fallback bookings. When the payer recovers, re-run the check, confirm the copay estimate, and only then treat coverage as known. We do not publish uptime percentages.
The sandbox includes outage payloads so engineers can test the fallback before it hits production. Read the longer write-up on detecting payer eligibility outages, or open the API docs.
What to track once eligibility is live
Insurance-step conversion
Share of patients who choose insurance and complete booking, by payer and by state. This is the number that moves.
Not-found rate
Checks that return no match. High rates point to a form problem, not a coverage problem.
Copay accuracy
Estimated vs collected at date of service. Keeps the front-end promise honest.
Questions, answered
What is a soft eligibility check?
A check run from name, date of birth, and payer (or a member ID if you have it) that returns coverage status, plan, and an estimated copay without asking the patient to upload a card or wait. It is the right check at booking. A hard check with full benefits detail runs before the visit.
How long does integration take?
Most teams ship the hosted widget in a day and the API in under a week. The sandbox returns the same payloads as production, including outage and not-found cases.
What is payer outage detection for eligibility?
Payer eligibility endpoints fail. The API returns a distinct outage status instead of treating the failure as "not covered," so eligibility verification at booking can let the patient continue and re-check before the visit. We do not publish uptime percentages.
What happens when a payer's eligibility system is down?
The API returns a distinct outage status rather than a false negative, so your booking flow can let the patient continue and re-check later. We monitor payer availability and surface it in the dashboard.
Can we show the patient their copay before they book?
Yes. The copay estimate API response includes an estimate based on the plan's benefit for the service type. Show it as an estimate; the final amount depends on deductible status at the date of service.
Does this work while we are on the rented PC?
Yes. Eligibility is entity-independent. The same integration keeps working as volume moves to your own PC.
Read the docs, then run a check in the sandbox.
Keys are issued in week one. Your engineers do not need to wait for enrollment.