Daybook DocsDaybook Docs
Browse
All use cases
Billing companies

Find a missing remit in the payer portal

When a payment shows up with no 835, Daybook signs in to the portal and brings the remit back.

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. payment.unmatched flags a deposit with no remit.

  2. Start a remit_lookup task for the claim with POST /v1/portal-tasks.

  3. Daybook signs in with the provider's portal account and captures every page as evidence.

  4. portal_task.completed carries the result to your posting team.

Replaces A poster signing in to a payer portal to hunt for one remit.

Built on

EventSent when
payment.unmatchedA payment or deposit has no match.
portal_task.completedThe task finished, with its result and evidence.
portal_task.failedThe task could not finish, 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: Find a missing remit in the payer portal
For: Billing companies
Outcome: When a payment shows up with no 835, Daybook signs in to the portal and brings the remit back.

What to build:
A handler that takes payment.unmatched, finds the claim it belongs to in our records, starts a portal task with POST /v1/portal-tasks (task remit_lookup, the claim and the provider's NPI and tax id), and on portal_task.completed attaches the result and the captured pages to the deposit for our posting team. portal_task.failed opens a task for a person with the reason.

How it works:
1. payment.unmatched flags a deposit with no remit.
2. Start a remit_lookup task for the claim with POST /v1/portal-tasks.
3. Daybook signs in with the provider's portal account and captures every page as evidence.
4. portal_task.completed carries the result to your posting team.

Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/payer-portals.md
- https://daybookhealthcare.com/docs/workflows/remittance.md
- https://daybookhealthcare.com/docs/api-reference/portal-tasks/create.md
- https://daybookhealthcare.com/docs/api-reference/portal-tasks/get.md
- https://daybookhealthcare.com/docs/api-reference/remits/list.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 /portal-tasks: Start a portal task
- GET /portal-tasks/{id}: Retrieve a portal task
- GET /remits: List remits

Webhook events: payment.unmatched, portal_task.completed, portal_task.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 how we record deposits and claims today, then show how a deposit links to its portal task before writing code.
On this pageHow it worksBuilt onThe promptRelated use cases