Real-time insurance eligibility API at booking. No card upload.
A soft check at booking uses name, date of birth, and payer and returns coverage, plan, and an estimated copay. When a payer endpoint fails, the API returns a distinct outage status instead of not covered, so booking can continue and the check can run again before the visit. Sandbox keys come first, so your engineers can test the outage path before launch.
Updated November 1, 2026
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. Outage signals come from live payer responses in the eligibility check, not a separate uptime dashboard.
The sandbox includes outage payloads so engineers can test the fallback before it hits production. Eligibility keeps working as you own your payer contracts.
If you are leaving a rental vendor, start with switching from a network rental vendor.
What to track once eligibility is live
Once those checks are live, the longer choice is whether to rent a PC or own one. Owning one is papered as an MSO-PC structure for telehealth.
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. Outage signals come from live payer responses in the eligibility check, not a separate uptime dashboard.
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.
What is the best real-time insurance eligibility API for a telehealth booking flow?
A soft check at booking uses name, date of birth, and payer and returns coverage, plan, and an estimated copay. When a payer endpoint fails, the API returns a distinct outage status instead of not covered, so booking can continue and the check can run again before the visit. Sandbox keys come first, so your engineers can test the outage path before launch.
Run a check in the sandbox.
Keys are issued in week one. Your engineers do not need to wait for enrollment.