Billing companies
Appeal letters drafted from denial data
A drafted appeal waiting for every denial worth fighting, inside its deadline.
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
denial.classified sorts the denial by cause, with its recommended action and appeal deadline.
Your rules pick the causes you appeal, such as missing authorization.
POST /v1/appeals drafts the letter with your signer.
appeal.drafted lands for a biller to review, edit and send.
Built on
| Event | Sent when |
|---|---|
denial.classified | A denial was read and sorted by cause. |
appeal.drafted | An appeal letter is ready to review, or Daybook refused with the reason. |
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: Appeal letters drafted from denial data
For: Billing companies
Outcome: A drafted appeal waiting for every denial worth fighting, inside its deadline.
What to build:
A service that takes denial.classified, keeps the cause and appeal deadline on our denial record, drafts an appeal with POST /v1/appeals for the causes we choose to appeal (signer from the client's settings), and on appeal.drafted puts the letter in a review queue sorted by deadline. When Daybook refuses to draft, the reason goes on the record for a biller.
How it works:
1. denial.classified sorts the denial by cause, with its recommended action and appeal deadline.
2. Your rules pick the causes you appeal, such as missing authorization.
3. POST /v1/appeals drafts the letter with your signer.
4. appeal.drafted lands for a biller to review, edit and send.
Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/denials-and-appeals.md
- https://daybookhealthcare.com/docs/api-reference/denials/get.md
- https://daybookhealthcare.com/docs/api-reference/appeals/create.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 /appeals: Draft an appeal
Webhook events: denial.classified, appeal.drafted
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 denial causes we appeal and where billers review letters today, then propose the queue and its sort order before writing code.