Daybook DocsDaybook Docs
Browse
All use cases
Billing companies

Post finished payer calls to Slack

Your team sees each payer's answer in a channel as a call ends, and a ping when a live rep is ready for a biller.

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. Register a webhook endpoint for call.completed, call.handoff_ready and call.failed.

  2. Send a test event to check the handler.

  3. Verify the signature, then post the status, reference number and next step to Slack.

  4. Post call.handoff_ready with the claim, so a biller can take the rep.

Built on

EventSent when
call.completedThe call ended with a structured answer, your metadata echoed.
call.handoff_readyA rep answered a handoff call. Carries the bridge details and the questions to ask.
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: Post finished payer calls to Slack
For: Billing companies
Outcome: Your team sees each payer's answer in a channel as a call ends, and a ping when a live rep is ready for a biller.

What to build:
A small webhook service that receives call.completed, call.handoff_ready and call.failed, verifies the Daybook signature, and posts a Slack message per event through an incoming webhook URL: for call.completed the payer, the claim's patient control number, status, reference number and next step; for call.handoff_ready an urgent message that a rep is waiting; for call.failed the reason. Register it with POST /v1/webhook-endpoints and check it with the test endpoint.

How it works:
1. Register a webhook endpoint for call.completed, call.handoff_ready and call.failed.
2. Send a test event to check the handler.
3. Verify the signature, then post the status, reference number and next step to Slack.
4. Post call.handoff_ready with the claim, so a biller can take the rep.

Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/payer-calls.md
- https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/create.md
- https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/test.md
- https://daybookhealthcare.com/docs/api-reference/calls/get.md
- https://daybookhealthcare.com/docs/webhooks.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 /webhook-endpoints: Create a webhook endpoint
- POST /webhook-endpoints/{id}/test: Send a test event
- GET /calls/{id}: Retrieve a call

Webhook events: call.completed, call.handoff_ready, 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 where to host the service and which Slack channel each event goes to, then write it with a test that replays a signed sample event.
On this pageHow it worksBuilt onThe promptRelated use cases