Built to plug into the systems you already run.
One API for the work around a claim: payer calls, portal sessions, clearinghouse transactions, remits and denials. Your systems ask, Daybook does the work, and a webhook brings the answer back.
- APIsStart a call, a status check or an appeal draft with one request.
- WebhooksSigned events the moment a payer answers or a remit arrives.
- MCPThe same operations as tools for your AI agents.
// Ask Daybook where a claim standsawait fetch("https://api.daybookhealthcare.com/v1/claim-status/checks", {method: "POST",headers: { Authorization: `Bearer ${DAYBOOK_API_KEY}` },body: JSON.stringify({payer: "bayline",claim: { patient_control_number: "A-20817-1" },}),});// Daybook calls you back when the answer changesapp.post("/daybook/webhooks", (req, res) => {const event = verify(req); // claim.status_changedwriteBack(event.data); // into your PM systemres.sendStatus(200);});
Infrastructure, not another screen
Every client runs a different clearinghouse, PM system and payer portal. Daybook puts all of them behind one API: ask about a claim and Daybook routes it, checks its status, enriches the answer and posts the remit, whichever systems that client runs. Your PM, EHR or billing platform asks over the API and hears back over webhooks, and your billers see one workflow for every claim.
Every workflow, one request away
Each one is an endpoint you call and events you receive.
See every workflow →- Payer calls
- A voice agent calls the payer, works the phone tree, waits on hold and returns a structured answer. Start one with one request.
- Payer portals
- Signs in to payer portals, runs a defined set of steps and reads the result back, with an approval where you want one.
- Claim status276/277
- Real-time and batch checks, re-run by your own rules on claims that go quiet.
claim.status_changedfires only when something moves. - Eligibility and benefits270/271
- Coverage and benefits in real time, one at a time or by the thousand.
- Remittance and posting835
- Every 835 matched to its claims and its deposit, with the posting entries proposed for you to approve.
- ERA and EFT enrollment
- Every provider enrolled with every payer for electronic remits and payments, and tracked to approval.
- Denials and appeals
- CARC and RARC codes read, each denial sorted by cause and every paid line checked against the contract. The appeal draft is one call away.
Calls the payer so your team doesn't
A voice agent works the payer's phone tree, waits on hold and asks the rep what your billers would ask. The answer comes back as data: the status, the reference number, the rep's name and the next step.
- Phone treesEvery payer line mapped, with the claim's own values beside each step.
- Knowledge baseYour call scripts and payer guides, followed as written.
- Voice agentsOn hold for you, with a live transcript and a hand-off when a person is needed.
// Call the payer about a claimawait fetch("https://api.daybookhealthcare.com/v1/calls", {method: "POST",headers: { Authorization: `Bearer ${DAYBOOK_API_KEY}` },body: JSON.stringify({payer: "bayline",call_type: "claim_status",claim: {patient_control_number: "A-10442-1",date_of_service: "2026-09-14",},patient: { member_id: "W000000001", date_of_birth: "1980-01-01" },provider: { npi: "1999999984" },schedule: { repeat_every_days: 5 },}),});
Your rules, run as code
Your billers' payer rules, call scripts and workarounds become rules Daybook follows the same way every time. Write them once against the API, and every account runs through them.
- Rules written as when and then, triggered by events or worklist conditions
- Deterministic, so the same claim gets the same answer every time
- Signed webhooks with retries and replay, so nothing is lost while you're down
From the articles
All articles →
