Daybook DocsDaybook Docs
Browse
All use cases
Billing companies

Call the payer from your denial queue

Every denial a phone call settles gets one, and the rep's answer lands back on the same ticket.

Build this with AIA brief with this use case's endpoints, events and rules, ready for your assistant to build it in your stack.

How it works

  1. denial.classified arrives with the cause, the recommended action and the appeal deadline.

  2. Your rules pick the denials a call settles and start one with POST /v1/calls, your ticket id in metadata.

  3. call.completed brings the status, reference number, rep name and next step, your metadata echoed.

  4. Your handler writes the answer onto the ticket and moves it to the right queue.

Replaces The status call a biller places by hand, hold included.

Built on

EventSent when
denial.classifiedA denial was read and sorted by cause.
call.completedThe call ended with a structured answer, your metadata echoed.
call.failedThe call could not be completed. ended_reason says why.

The prompt

Paste it into Claude, Codex, Cursor or ChatGPT. It links the docs pages it needs, so your assistant builds against the real API.

I'm building on the Daybook API (healthcare billing: payer calls, payer portals, 270/271 eligibility, 276/277 claim status, 835 remits, denials and appeals). Help me build this end to end.

Use case: Call the payer from your denial queue
For: Billing companies
Outcome: Every denial a phone call settles gets one, and the rep's answer lands back on the same ticket.

What to build:
A worker that listens for denial.classified, reads the denial with GET /v1/denials/{id}, decides from a small rules table keyed by cause whether a payer call settles it, starts the call with POST /v1/calls (call_type claim_status, my ticket id and account in metadata), and on call.completed writes the status, reference number, rep name and next step back onto the ticket in my work queue. call.failed puts the ticket back in the queue with the reason.

How it works:
1. denial.classified arrives with the cause, the recommended action and the appeal deadline.
2. Your rules pick the denials a call settles and start one with POST /v1/calls, your ticket id in metadata.
3. call.completed brings the status, reference number, rep name and next step, your metadata echoed.
4. Your handler writes the answer onto the ticket and moves it to the right queue.

Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/payer-calls.md
- https://daybookhealthcare.com/docs/workflows/denials-and-appeals.md
- https://daybookhealthcare.com/docs/api-reference/denials/get.md
- https://daybookhealthcare.com/docs/api-reference/calls/create.md
- https://daybookhealthcare.com/docs/api-reference/calls/get.md
- https://daybookhealthcare.com/docs/webhooks/verifying-signatures.md
- https://daybookhealthcare.com/docs/idempotency-and-errors.md

Endpoints (base https://api.daybookhealthcare.com/v1):
- GET /denials/{id}: Retrieve a denial
- POST /calls: Start a call
- GET /calls/{id}: Retrieve a call

Webhook events: denial.classified, call.completed, call.failed

Ground rules:
- Authenticate with the header Authorization: Bearer <key>, the key read from DAYBOOK_API_KEY. sk_test_ keys open a sandbox and sk_live_ keys reach real payers. Never hard-code a key. Details: https://daybookhealthcare.com/docs/authentication.md
- Send an Idempotency-Key on every POST: a fresh UUID per operation, reused only to retry that operation. A key reused with a different body answers 409 idempotency_conflict.
- Verify every webhook signature before trusting the event, answer 2xx at once and do the work after.
- Keep my own ids beside Daybook's, and pass them in metadata where an endpoint takes it.
- Money is integer cents.
- Tests and fixtures use made-up data only: the sample payers bayline, keystone and meridian, NPI 1999999984, member W000000001, claim ids like clm_8Hq2Lm. Never real patient data.
- Use only the fields, endpoints and events in the docs. If something is missing, ask me rather than guess.

Ask me which work queue or PM system holds our tickets and how a note is written to one, then propose the rules table and the file layout before writing code.
On this pageHow it worksBuilt onThe promptRelated use cases