Daybook DocsDaybook Docs
Browse
All use cases
Billing companies

Recheck silent claims by phone until they move

Claims with no 276/277 answer get a payer call that repeats every few days and stops once the claim is paid.

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. A rule finds claims with no response after 30 days.

  2. Start a repeating call with POST /v1/calls: repeat every 5 days until the status changes.

  3. Each run sends call.completed with repeat_of and the same metadata.

  4. When remit.received shows the claim paid, stop the series with POST /v1/calls/{id}/cancel.

Replaces A follow-up reminder a biller sets, and the call they make each time it fires.

Built on

EventSent when
claim.status_changedA claim's status differs from the last check.
call.completedThe call ended with a structured answer, your metadata echoed.
remit.receivedA new 835 arrived.

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: Recheck silent claims by phone until they move
For: Billing companies
Outcome: Claims with no 276/277 answer get a payer call that repeats every few days and stops once the claim is paid.

What to build:
A loop for silent claims: a rule made once with POST /v1/rules flags claims with no response after 30 days; my handler starts a repeating claim status call for each with POST /v1/calls (schedule repeat_every_days 5 until status_changes, my ticket in metadata) and keeps the first call's id; call.completed for every run (marked by repeat_of) updates the ticket; and when remit.received shows the claim paid, POST /v1/calls/{id}/cancel stops the series with the reason.

How it works:
1. A rule finds claims with no response after 30 days.
2. Start a repeating call with POST /v1/calls: repeat every 5 days until the status changes.
3. Each run sends call.completed with repeat_of and the same metadata.
4. When remit.received shows the claim paid, stop the series with POST /v1/calls/{id}/cancel.

Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/claim-status.md
- https://daybookhealthcare.com/docs/workflows/payer-calls.md
- https://daybookhealthcare.com/docs/workflows/remittance.md
- https://daybookhealthcare.com/docs/api-reference/rules/create.md
- https://daybookhealthcare.com/docs/api-reference/calls/create.md
- https://daybookhealthcare.com/docs/api-reference/calls/cancel.md
- https://daybookhealthcare.com/docs/webhooks/verifying-signatures.md
- https://daybookhealthcare.com/docs/idempotency-and-errors.md

Endpoints (base https://api.daybookhealthcare.com/v1):
- POST /rules: Create a rule
- POST /calls: Start a call
- POST /calls/{id}/cancel: Cancel a call

Webhook events: claim.status_changed, call.completed, remit.received

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 where we track open tickets, then show the state each claim moves through before writing code.
On this pageHow it worksBuilt onThe promptRelated use cases