# Daybook Health developer docs

> The Daybook API, webhooks and MCP server, every page of https://daybookhealthcare.com/docs as Markdown. The short index is https://daybookhealthcare.com/llms.txt; the OpenAPI spec is https://daybookhealthcare.com/docs/openapi.json.

## Daybook docs

APIs and webhooks that plug payer calls, portal work, clearinghouse transactions, remits and denials into the systems you already run.

Source: https://daybookhealthcare.com/docs

### Pages

- [Quickstart](https://daybookhealthcare.com/docs/quickstart.md): Make your first request and receive your first webhook: check a claim's status, then send a signed test event to your endpoint.
- [Accounts](https://daybookhealthcare.com/docs/accounts.md): The two kinds of account, sandbox and production, how to get one, how to sign in to the Daybook app, and moving to production for real payers.
- [Sandbox sample files](https://daybookhealthcare.com/docs/sandbox-sample-files.md): A made-up billing company's rosters, claims, remits and open stays to upload to your sandbox, so you can see matching, flags and posting with data in place.
- [Forward-deployed engineering](https://daybookhealthcare.com/docs/forward-deployed-engineering.md): A Daybook engineer wires Daybook into your systems, builds the write-back, and builds the screens you're missing on the same API.
- [How Daybook fits](https://daybookhealthcare.com/docs/how-daybook-fits.md): Where Daybook sits between your PM system, your clearinghouse and the payer, and what stays where.
- [Authentication](https://daybookhealthcare.com/docs/authentication.md): API keys for sandbox and production accounts, and keeping keys safe.
- [Worklists and rules](https://daybookhealthcare.com/docs/worklists-and-rules.md): Send the accounts you already work, and the rules that decide what happens to each one.
- [Idempotency and errors](https://daybookhealthcare.com/docs/idempotency-and-errors.md): Retry safely with idempotency keys, and read every error the same way.
- [API reference](https://daybookhealthcare.com/docs/api-reference.md): A REST API over JSON: predictable resources, bearer keys, idempotent writes and signed webhooks.
- [Webhooks](https://daybookhealthcare.com/docs/webhooks.md): Daybook posts signed events to the HTTPS endpoints you register, and records every delivery.
- [Event types](https://daybookhealthcare.com/docs/webhooks/event-types.md): The events Daybook sends, and the data each one carries.
- [Verifying signatures](https://daybookhealthcare.com/docs/webhooks/verifying-signatures.md): Check that every event came from Daybook and wasn't replayed, in Node, Python or Rust.
- [Deliveries and testing](https://daybookhealthcare.com/docs/webhooks/deliveries.md): The delivery log for each endpoint, and how to send a test event.
- [Model Context Protocol](https://daybookhealthcare.com/docs/mcp.md): Give Claude, Cursor or your own agents Daybook as tools: read claims, payer calls, denials and remits, start a call and record the work.
- [Connect a client](https://daybookhealthcare.com/docs/mcp/connect.md): Add Daybook's MCP server to Claude, Claude Desktop, Claude Code, Cursor, VS Code or your own agent, with a token that acts as you.
- [Tools](https://daybookhealthcare.com/docs/mcp/tools.md): Every tool on Daybook's MCP server by area: what it reads or does, and the API page that does the same from code.
- [Playbooks](https://daybookhealthcare.com/docs/mcp/playbooks.md): Ready-made prompts on Daybook's MCP server: work a denial, chase a flagged payment, post a remit, check a claim, plan a shift.
- [Payer calls from Claude](https://daybookhealthcare.com/docs/mcp/payer-calls.md): Connect Daybook's voice agent to Claude: start a payer call from a chat, read the answer and transcript, and record the outcome on the claim.
- [Permissions and safety](https://daybookhealthcare.com/docs/mcp/permissions.md): What an AI agent connected to Daybook can see and do, what it never sees, what waits for a person, and how its work is recorded.
- [Build with AI](https://daybookhealthcare.com/docs/mcp/build-with-ai.md): Every Daybook docs page as Markdown for your AI assistant, llms.txt, Copy page and Ask AI, and use case prompts that build an integration.
- [APIs by workflow](https://daybookhealthcare.com/docs/workflows.md)
- [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls.md): Call the payer, work the phone tree, wait on hold, and get a structured answer back.
- [Payer portals](https://daybookhealthcare.com/docs/workflows/payer-portals.md): Sign in to payer portals, run a defined set of steps, and read the result back.
- [ERA and EFT enrollment](https://daybookhealthcare.com/docs/workflows/enrollment.md): Enroll every provider with every payer for electronic remits and payments, and track it to approval.
- [Eligibility and benefits](https://daybookhealthcare.com/docs/workflows/eligibility.md): Check coverage and benefits over 270/271 in real time, one at a time or by the thousand.
- [Claim status](https://daybookhealthcare.com/docs/workflows/claim-status.md): 276/277 claim status checks in real time and at volume, kicked off by your own rules.
- [Remittance and posting](https://daybookhealthcare.com/docs/workflows/remittance.md): Pull 835s, match them to claims and deposits, and propose the posting entries for each payment.
- [Denials and appeals](https://daybookhealthcare.com/docs/workflows/denials-and-appeals.md): Read CARC and RARC codes, sort each denial by cause, trigger the next step, and draft the appeal.
- [Use cases](https://daybookhealthcare.com/docs/use-cases.md): What teams build on the Daybook API, from denial call queues to 835 posting, each with its endpoints, its steps and a prompt for Claude, ChatGPT or Cursor.
- [Start a call](https://daybookhealthcare.com/docs/api-reference/calls/create.md): `POST /v1/calls`
- [Retrieve a call](https://daybookhealthcare.com/docs/api-reference/calls/get.md): `GET /v1/calls/{id}`
- [List calls](https://daybookhealthcare.com/docs/api-reference/calls/list.md): `GET /v1/calls`
- [Cancel a call](https://daybookhealthcare.com/docs/api-reference/calls/cancel.md): `POST /v1/calls/{id}/cancel`
- [Tell the agent something](https://daybookhealthcare.com/docs/api-reference/calls/instruct.md): `POST /v1/calls/{id}/instruct`
- [Read the transcript](https://daybookhealthcare.com/docs/api-reference/calls/transcript.md): `GET /v1/calls/{id}/transcript`
- [Start a portal task](https://daybookhealthcare.com/docs/api-reference/portal-tasks/create.md): `POST /v1/portal-tasks`
- [Retrieve a portal task](https://daybookhealthcare.com/docs/api-reference/portal-tasks/get.md): `GET /v1/portal-tasks/{id}`
- [Approve a portal action](https://daybookhealthcare.com/docs/api-reference/portal-tasks/approve.md): `POST /v1/portal-tasks/{id}/approve`
- [Submit an enrollment](https://daybookhealthcare.com/docs/api-reference/enrollments/create.md): `POST /v1/enrollments`
- [Retrieve an enrollment](https://daybookhealthcare.com/docs/api-reference/enrollments/get.md): `GET /v1/enrollments/{id}`
- [Check eligibility](https://daybookhealthcare.com/docs/api-reference/eligibility/create-check.md): `POST /v1/eligibility/checks`
- [Check claim status](https://daybookhealthcare.com/docs/api-reference/claim-status/create-check.md): `POST /v1/claim-status/checks`
- [List remits](https://daybookhealthcare.com/docs/api-reference/remits/list.md): `GET /v1/remits`
- [Retrieve a remit](https://daybookhealthcare.com/docs/api-reference/remits/get.md): `GET /v1/remits/{id}`
- [Approve a posting](https://daybookhealthcare.com/docs/api-reference/remits/approve-posting.md): `POST /v1/remits/{id}/posting/approve`
- [Retrieve a denial](https://daybookhealthcare.com/docs/api-reference/denials/get.md): `GET /v1/denials/{id}`
- [Draft an appeal](https://daybookhealthcare.com/docs/api-reference/appeals/create.md): `POST /v1/appeals`
- [Create a worklist](https://daybookhealthcare.com/docs/api-reference/worklists/create.md): `POST /v1/worklists`
- [Create a rule](https://daybookhealthcare.com/docs/api-reference/rules/create.md): `POST /v1/rules`
- [Create a webhook endpoint](https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/create.md): `POST /v1/webhook-endpoints`
- [List webhook endpoints](https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/list.md): `GET /v1/webhook-endpoints`
- [Delete a webhook endpoint](https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/delete.md): `DELETE /v1/webhook-endpoints/{id}`
- [Send a test event](https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/test.md): `POST /v1/webhook-endpoints/{id}/test`

OpenAPI: https://daybookhealthcare.com/docs/openapi.json

---

## Quickstart

Make your first Daybook API request and receive your first webhook: check a claim's status over 276/277 and get the answer back in your own system.

Source: https://daybookhealthcare.com/docs/quickstart

This guide checks a claim's status, then sends a signed test event to your own endpoint. It takes about five minutes.

#### 1. Get your API keys

Create a free [sandbox account](https://daybookhealthcare.com/docs/accounts), then open **Developers → API keys** in the Daybook app and create a key. The key is shown once, when you create it; copy it to your secrets manager then.

- `sk_test_...` keys belong to a sandbox account and open only that account. A sandbox is a real workspace with every capability of production: its clearinghouse requests go to Stedi's test payers and members when Daybook has given it a Stedi test key, its webhook events carry `mode: test`, and a payer call placed from it is a real call. See [Sandbox and payer calls](https://daybookhealthcare.com/docs/authentication#sandbox-and-payer-calls).
- `sk_live_...` keys belong to a production account and reach real payers. Production accounts are set up with our team: [book a demo](https://daybookhealthcare.com/book-a-demo).

Keep keys on your server. Never ship them to a browser or a mobile app.

```bash
export DAYBOOK_API_KEY=sk_test_...
```

#### 2. Register a webhook endpoint

Tell Daybook where to send events: open **Developers → Webhooks** in the Daybook app, add an endpoint with its HTTPS URL, and choose its event types, or `*` for all. Any HTTPS URL works; for local testing, a tunnel such as `cloudflared` is fine.

Daybook shows the endpoint's signing secret, starting `whsec_`, once. Store it: you use it to [verify signatures](https://daybookhealthcare.com/docs/webhooks/verifying-signatures).

#### 3. Check a claim's status

```bash
curl https://api.daybookhealthcare.com/v1/claim-status/checks \
  -H "Authorization: Bearer $DAYBOOK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "payer": "keystone",
    "provider": { "npi": "1999999984" },
    "patient": {
      "first_name": "Jordan", "last_name": "Sample",
      "date_of_birth": "1980-01-01", "member_id": "W000000001"
    },
    "claim": { "patient_control_number": "A-20817-1", "date_of_service": "2026-09-30" }
  }'
```

The answer comes back in the response, normalized from the 277:

```json
{
  "id": "cs_01JBXE4H9M2T",
  "object": "claim_status_check",
  "status": "complete",
  "claim_status": {
    "category": "paid",
    "category_code": "F1",
    "paid_amount_cents": 31200,
    "check_or_eft_number": "EFT00048213"
  },
  "changed": true
}
```

#### 4. Receive a test event

Choose **Send test event** on the endpoint's page, or call [Send a test event](https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/test). Daybook signs a `webhook.test` event and posts it to your endpoint. Verify the signature, return `2xx` quickly, and do the work after. The delivery shows on the endpoint's page.

Node (Express):

```javascript
import express from "express";
import { verifyDaybookWebhook } from "./verify.js";

const app = express();

app.post("/daybook/webhooks", express.raw({ type: "application/json" }), (req, res) => {
  const event = verifyDaybookWebhook(
    req.body,
    req.headers,
    process.env.DAYBOOK_WEBHOOK_SECRET,
  );
  res.sendStatus(200);

  if (event.type === "webhook.test") {
    console.log(event.data.message);
  }
});
```

Python (Flask):

```python
import os
from flask import Flask, request
from verify import verify_daybook_webhook

app = Flask(__name__)

@app.post("/daybook/webhooks")
def daybook_webhook():
    event = verify_daybook_webhook(
        request.get_data(),
        request.headers,
        os.environ["DAYBOOK_WEBHOOK_SECRET"],
    )
    if event["type"] == "webhook.test":
        print(event["data"]["message"])
    return "", 200
```

`verifyDaybookWebhook` is twenty lines; copy it from [Verifying signatures](https://daybookhealthcare.com/docs/webhooks/verifying-signatures).

### Next steps

- [APIs by workflow](https://daybookhealthcare.com/docs/workflows): Pick the workflow you want to plug in.
- [Rules](https://daybookhealthcare.com/docs/worklists-and-rules): Let Daybook start checks and calls on its own, from your rules.
- [Event types](https://daybookhealthcare.com/docs/webhooks/event-types): The events Daybook sends, and their data.
- [MCP](https://daybookhealthcare.com/docs/mcp): Give your agents the same operations as tools.

---

## Accounts

Daybook's sandbox accounts on Stedi's test payers and production accounts for real payers, how to get one, and signing in with Google or an email link.

Source: https://daybookhealthcare.com/docs/accounts

Everything you build against Daybook belongs to an account: its people, API keys, webhook endpoints and data. There are two kinds, and anyone can open the first.

|  | Sandbox | Production |
| --- | --- | --- |
| Who opens it | You, from the sign-up page, in a minute | Our team, with you ([book a demo](https://daybookhealthcare.com/book-a-demo)) |
| Payers | Clearinghouse requests go to Stedi's test payers and members when Daybook has given the sandbox a Stedi test key. Payer calls are real calls through the same voice agent ([Sandbox and payer calls](https://daybookhealthcare.com/docs/authentication#sandbox-and-payer-calls)) | Real payers, portals and clearinghouses |
| Data | Test data only. Use made-up patients, never real ones | Your firm's real claims and patients |
| Business Associate Agreement | None to sign | Signed through DocuSign before any data goes in |
| API keys | `sk_test_...` | `sk_live_...` |

### Create a sandbox account

#### 1. Open the sign-up page

Go to [Get started](https://daybookhealthcare.com/get-started) and choose **Create a sandbox account**, or open the [sign-up page](https://app.daybookhealthcare.com/sign-up) directly.

#### 2. Give your work email

Daybook emails you a link that creates the sandbox. Or choose **Continue with Google**.

#### 3. Open the link

The link works once and expires soon. It creates your sandbox and signs you in as its owner. Setting up takes under a minute, then the app opens on your workspace.

The switcher at the top left shows **Sandbox** while you work in one. From there, open **Developers → API keys** and **Developers → Webhooks** to follow the [Quickstart](https://daybookhealthcare.com/docs/quickstart).

### Sign in

Sign in at [app.daybookhealthcare.com/sign-in](https://app.daybookhealthcare.com/sign-in) with Google, or with your work email: Daybook emails you a link that signs you in. Each link works once, and you can open it on this device or another one. There are no passwords.

To bring teammates in, the account owner invites them from **Settings → Team** in the app. An invitation signs the new member in to your account.

### Move to production

When you are ready for real payers, [book a demo](https://daybookhealthcare.com/book-a-demo). On the go-live call our team turns on production for your firm, and its owner signs the Business Associate Agreement.

> A production account is a separate account. Its API keys, webhook endpoints and data start fresh: create `sk_live_` keys and register your endpoints there, and keep the sandbox for testing.

---

## Sandbox sample files

Download a made-up billing company's rosters, claims and remits, upload them to your Daybook sandbox, and see matching, flags and posting.

Source: https://daybookhealthcare.com/docs/sandbox-sample-files

A sandbox starts empty. If you do not have test files to hand, use these: a made-up billing company with 3 practices, 9 providers, 5 payers, 120 claims, the remits that came back and 7 open stays. They go through the same uploads your own files would.

[Download the sample files](https://daybookhealthcare.com/sandbox/daybook-sandbox-sample-files.zip) (zip, under 100 KB).

> Every practice, provider, payer, patient, resident, member id, NPI and tax id in these files is made up. Upload them to a sandbox only, never to a production account.

### Upload them in this order

#### 1. Rosters and rates

In the Daybook app, open **Settings → Data imports**. Upload files `01` to `05` in order, and accept each preview. Rates must go in before the remits: a remit is priced when it lands.

#### 2. Claims

On the same page, upload the three `07-claims` files and accept each one.

#### 3. Remits

Open **Payments → Remittances** and upload the ten `08-remit` files. Each one lands held, for you to review and post.

#### 4. Stays

Back on **Settings → Data imports**, choose **Authorizations** and upload `09-stays.csv`. It is laid out as a facility census export, with the resident's name as `Last, First` and US dates, and Daybook reads it with no column mapping.

### What you should see

| Where | What |
| --- | --- |
| Practices | Lantern Creek Family Medicine, Saltmarsh Counseling Group and Mosswood Dermatology, under one firm |
| Remittances | Each remit balanced to the cent, with its claims matched and the raw 835 beside them |
| Underpayments | 19 claims flagged, $330.83 short in all, each against its contract rate |
| Worklist | Denials and flagged payments to work, and 21 claims with no remit yet |
| Authorizations | 7 stays across the three practices, each requested and waiting on its payer |

---

## Forward-deployed engineering

How a Daybook forward-deployed engineer wires the API into your PM system, builds the write-back and builds missing screens on the same public API.

Source: https://daybookhealthcare.com/docs/forward-deployed-engineering

The API and webhooks are how Daybook connects to your systems. A forward-deployed engineer (FDE) is how that connection gets built when you'd rather not build it yourself.

An FDE works inside your stack for a defined engagement: they map Daybook's events onto your PM system, worklists and reports, build the write-back, and, where your team needs a screen that doesn't exist yet, build it on top of the same public API you'd use.

### What an engagement covers

- **Write-back**: Call answers, claim statuses, postings and denial causes land in the system your team already works in.
- **Your rules, encoded**: Your rules, call scripts and training docs become [rules](https://daybookhealthcare.com/docs/worklists-and-rules) Daybook follows.
- **Inputs from what you have**: Your existing worklists and exports become Daybook input. You don't rebuild your data collection.
- **Front end on the API**: Where a workflow needs a screen, the FDE builds it on the Daybook API, so it keeps working as Daybook grows.

### How it runs

#### 1. Pick the workflow

One workflow per engagement to start, such as claim status follow-up or ERA enrollment, with the volume and the systems it touches.

#### 2. Map inputs and write-back

Which export feeds it, which events come back, and where each one lands.

#### 3. Build and run side by side

Daybook runs the workflow next to your team until the results match what a biller would have done.

#### 4. Hand over

You own the integration. It runs on the public API and webhooks, documented here.

- [Talk to us about an engagement](https://daybookhealthcare.com/book-a-demo): Tell us the workflow and the systems involved.

---

## How Daybook fits

Where Daybook sits between your PM system, your clearinghouse and the payer, what stays in your systems, and how the API, webhooks and MCP connect them.

Source: https://daybookhealthcare.com/docs/how-daybook-fits

Daybook does not replace your PM system, your EHR or your clearinghouse. It sits beside them and does the work in between: the calls, the portal sessions, the status checks, reading every remit and denial. Your systems ask Daybook over the API and hear back over webhooks.

- **Your systems**: PM, EHR and worklists. They send requests and receive webhooks.
- **Daybook**: Runs the calls, portal sessions and clearinghouse transactions, and reads every answer.
- **Payers**: Reached by phone, through their portals, and over 270, 276 and 835 via the clearinghouse.

### What stays where

|  | Your systems | Daybook |
| --- | --- | --- |
| **Patients and claims** | The record of truth | Reads what each task needs |
| **Worklists** | Where your team works | Takes them as input, reports back per item |
| **Rules** | Your policies and scripts | Follows them as written |
| **Payer contact** |  | Calls, portals and clearinghouse transactions |
| **Results** | Written back to the account | Sent as API responses and webhooks |

### Three ways in

- [APIs](https://daybookhealthcare.com/docs/api-reference): Your systems ask.
- [Webhooks](https://daybookhealthcare.com/docs/webhooks): Daybook tells you.
- [MCP](https://daybookhealthcare.com/docs/mcp): Your agents ask.

---

## Authentication

How to authenticate to the Daybook API: bearer API keys for sandbox and production accounts, and keeping keys safe, for every endpoint you call.

Source: https://daybookhealthcare.com/docs/authentication

Every request carries a secret key as a bearer token.

```bash
curl https://api.daybookhealthcare.com/v1/remits \
  -H "Authorization: Bearer $DAYBOOK_API_KEY"
```

### Sandbox and production

| Key prefix | Account | Opens |
| --- | --- | --- |
| `sk_test_` | Sandbox | That sandbox account only. A production account refuses it |
| `sk_live_` | Production | That production account only. A sandbox refuses it |

A sandbox account and a production account are separate accounts, each with its own keys, webhook endpoints and data. Anyone can open a [sandbox account](https://daybookhealthcare.com/get-started); a production account is set up with our team ([book a demo](https://daybookhealthcare.com/book-a-demo)).

Isolation follows from that: a key sees only its own account's objects, and an id from another account answers `404`, never a hint that it exists. Create one key per system that calls Daybook, so a queue, a dashboard and a CI job can each be revoked alone.

### Sandbox and payer calls

A sandbox is a real Daybook workspace with every capability of a production one. Nothing is switched off there, so what you try in the sandbox is what your production workspace will do. Three things differ: its keys are `sk_test_`, its webhook events carry `mode: test`, and its clearinghouse traffic goes to Stedi's test environment when Daybook has given it a Stedi test key, which is how Daybook sets sandboxes up. A Stedi account you connect yourself is a production account and reaches real payers from a sandbox too; ask your Daybook contact which your sandbox uses.

### Creating and revoking keys

Keys are created and revoked from **Developers → API keys** in the Daybook app, by the account owner or anyone who manages its integrations. A key is shown once, when it is created; Daybook keeps only a hash of it. An account holds up to 10 active keys.

### Keeping keys safe

Secret keys act on your behalf with payers. Use them only on your server.

- Store keys in your secrets manager, not in code or config files.
- Create one key per system so you can revoke one without touching the rest.
- To replace a key, create a new key, deploy it, then revoke the old one. A revoked key stops working at once.

### Errors

A missing or wrong key returns `401` with `authentication_failed`. A key without access to an object returns `404`, so ids from other accounts can't be probed. A route a key may not use at all, returns `403`. See [Idempotency and errors](https://daybookhealthcare.com/docs/idempotency-and-errors).

---

## Worklists and rules

Send Daybook the accounts you already work as a worklist, and write the rules that decide what runs on each one, such as re-checking quiet claims.

Source: https://daybookhealthcare.com/docs/worklists-and-rules

Daybook runs on your data and your rules. You don't rebuild your data collection: send the worklists and exports you already have, and write down what you'd tell a biller. Daybook does exactly that, then moves on to the next account.

### Worklists

A worklist is a set of accounts: the AR report, the denial queue, tomorrow's schedule. Send it as JSON items or as a link to an export from your PM system. Daybook maps the standard columns (payer, member, claim, balance) and keeps the rest as metadata, so every result comes back with your own ids.

POST /v1/worklists:

```json
{
  "name": "AR over 30 days",
  "csv_url": "https://example.com/exports/ar-30.csv?token=...",
  "rules": ["rule_01JBXJ1"]
}
```

### Rules

A rule is **when** plus **then**. The trigger is an event or a condition on worklist items. The action is anything you can do through the API.

Chase silent claims:

```json
{
  "name": "Chase silent claims",
  "when": { "condition": "days_since_submission >= 30 and status == \"no_response\"" },
  "then": { "action": "claim_status.check" }
}
```

Call when status stalls:

```json
{
  "name": "Call after two pending checks",
  "when": { "event": "claim.status_changed", "filter": { "current": "pending", "consecutive": 2 } },
  "then": { "action": "call.start", "params": { "call_type": "claim_status", "schedule": { "repeat_every_days": 5 } } }
}
```

Appeal missing auth:

```json
{
  "name": "Appeal missing auth",
  "when": { "event": "denial.classified", "filter": { "cause": "missing_auth" } },
  "then": { "action": "appeal.draft" }
}
```

### Scripts and training docs

Call scripts and training docs become the instructions Daybook follows on payer calls and in portals. Upload them in the Daybook app and reference them by id, such as the `script` field on [Start a call](https://daybookhealthcare.com/docs/api-reference/calls/create). On a call started from a claim in the app, the voice agent follows the call script that fits the claim's open step.

### Results

Every item reports back the way you choose: over the API, as webhooks, or as a file you pull into your PM system.

---

## Idempotency and errors

Retry Daybook API requests safely with idempotency keys, and read every error the same way, whichever payer workflow endpoint returned it.

Source: https://daybookhealthcare.com/docs/idempotency-and-errors

### Idempotency

Payer work has side effects: a call gets placed, a portal form gets submitted. Send an `Idempotency-Key` header on every `POST` so a retry after a timeout never does the work twice.

```bash
-H "Idempotency-Key: $(uuidgen)"
```

- Use a fresh UUID per operation, and reuse it only to retry that operation.
- Daybook keeps keys for 24 hours. A repeat within that window returns the original response.
- The same key with a different body returns `409 idempotency_conflict`.

### Errors

Every error has the same shape.

```json
{
  "error": {
    "type": "invalid_request",
    "code": "missing_field",
    "message": "patient.member_id is required for claim_status calls.",
    "field": "patient.member_id",
    "request_id": "req_01JBXV2Q"
  }
}
```

| Status | type | Meaning |
| --- | --- | --- |
| `400` | `invalid_request` | A field is missing or wrong. `field` names it. |
| `401` | `authentication_failed` | Missing or wrong API key. |
| `404` | `not_found` | No such object for this key. |
| `409` | `conflict` | Idempotency conflict, or the object is in the wrong state (approving a task that isn't waiting). |
| `422` | `payer_rejected` | The payer or clearinghouse rejected the request. `code` carries the payer's reason, such as an AAA code. |
| `429` | `rate_limited` | Slow down. `Retry-After` says for how long. |
| `5xx` | `api_error` | Our side. Retry with the same idempotency key. |

Quote the `request_id` when you contact us.

### Money and dates

Amounts are integer cents (`31200` is $312.00). Dates are `YYYY-MM-DD`; timestamps are RFC 3339 in UTC.

---

## API reference

The Daybook REST API reference: every endpoint for payer calls, portals, eligibility, claim status, remits, enrollment and denials, with examples.

Source: https://daybookhealthcare.com/docs/api-reference

### Base URL

```text
https://api.daybookhealthcare.com/v1
```

### OpenAPI spec

The whole API as an OpenAPI 3.1 document, for code generators, API clients and agents: [/docs/openapi.json](https://daybookhealthcare.com/docs/openapi.json). Every docs page is also plain Markdown at its own URL with `.md` on the end, such as [/docs/quickstart.md](https://daybookhealthcare.com/docs/quickstart.md).

### Conventions

- [Authentication](https://daybookhealthcare.com/docs/authentication): `Authorization: Bearer sk_live_...` on every request. `sk_test_` keys reach the sandbox.
- [Idempotency](https://daybookhealthcare.com/docs/idempotency-and-errors): Send `Idempotency-Key` on every `POST`. A retry never places a call or submits a form twice.
- [Async by default](https://daybookhealthcare.com/docs/webhooks): Calls, portal tasks, enrollments and batches return right away; the result arrives as a webhook.
- [Money and dates](https://daybookhealthcare.com/docs/idempotency-and-errors): Integer cents. `YYYY-MM-DD` dates. RFC 3339 timestamps in UTC.

### Metadata

Most objects take `metadata`: up to 20 keys of your own, such as your account, ticket or claim id. Metadata is echoed on the object and on every event about it, so your webhook handler never needs a lookup table. Keep it to ids: a patient's name, date of birth or member id belongs in the request's own fields, never in metadata, which is echoed everywhere and will land in your logs.

### Pagination

List endpoints return `data` and `has_more`. Pass the last id as `starting_after` for the next page.

---

## Webhooks

How Daybook webhooks work: signed events posted to the HTTPS endpoints you register, the event envelope, and a log of every delivery.

Source: https://daybookhealthcare.com/docs/webhooks

Register an HTTPS endpoint in **Developers → Webhooks** in the Daybook app. Daybook signs every event it sends with the endpoint's secret and records each delivery on the endpoint's page. **Send test event** posts a `webhook.test` event, so you can check your handler end to end.

### The event envelope

Every event has the same outer shape.

- `id` (string): Unique id: `evt_` and a ULID. The same value as the `webhook-id` header. Use it to drop duplicates.
- `type` (string): Such as `webhook.test`. See [Event types](https://daybookhealthcare.com/docs/webhooks/event-types).
- `created_at` (string): RFC 3339 timestamp.
- `mode` (string): `test` from a sandbox account, `live` from a production account.
- `data` (object): The event's data. See [Event types](https://daybookhealthcare.com/docs/webhooks/event-types).

```json
{
  "id": "evt_01JBXK8N3QZ7V2C4D5E6F7G8HJ",
  "type": "webhook.test",
  "created_at": "2026-10-29T14:31:40Z",
  "mode": "test",
  "data": {
    "endpoint_id": "whe_01JBXK4R7T2M9P5W3Y6A8C0D1E",
    "message": "This is a test event from Daybook."
  }
}
```

### Handling events well

#### 1. Verify the signature

Reject anything without a valid `webhook-signature`. See [Verifying signatures](https://daybookhealthcare.com/docs/webhooks/verifying-signatures).

#### 2. Return 2xx fast

Daybook waits 10 seconds for your answer. Any other status, or no answer in that time, is recorded as a failed delivery. Acknowledge first, then do the work in the background.

#### 3. Drop duplicates

Keep the `id`s you've processed and skip any you've seen. A delivery that failed is tried again with the same `id`, so the same event can reach you more than once.

- [Event types](https://daybookhealthcare.com/docs/webhooks/event-types): The events Daybook sends.
- [Verifying signatures](https://daybookhealthcare.com/docs/webhooks/verifying-signatures): Standard Webhooks, in your language.
- [Deliveries and testing](https://daybookhealthcare.com/docs/webhooks/deliveries): The delivery log and test events.

---

## Event types

The webhook events Daybook sends and the data each one carries, starting with webhook.test, the signed test event you send from the app or the API.

Source: https://daybookhealthcare.com/docs/webhooks/event-types

Every event arrives in the same [envelope](https://daybookhealthcare.com/docs/webhooks). Subscribe an endpoint to exact types, or `*` for all.

| Event | Sent when |
| --- | --- |
| `webhook.test` | You choose **Send test event** on an endpoint's page in **Developers → Webhooks**, or call [Send a test event](https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/test). |

### webhook.test

- `data.endpoint_id` (string): The endpoint the event was sent to, prefixed `whe_`.
- `data.message` (string): A fixed message saying this is a test event.

```json
{
  "id": "evt_01JBXK8N3QZ7V2C4D5E6F7G8HJ",
  "type": "webhook.test",
  "created_at": "2026-10-29T14:31:40Z",
  "mode": "test",
  "data": {
    "endpoint_id": "whe_01JBXK4R7T2M9P5W3Y6A8C0D1E",
    "message": "This is a test event from Daybook."
  }
}
```

### Payer call events

The [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls) workflow sends these events as a call moves. Each arrives in the same envelope, with the call object in `data` and your `metadata` echoed.

| Event | Sent when |
| --- | --- |
| `call.started` | Daybook dialed and is working the phone tree. |
| `call.on_hold` | Daybook reached the hold queue. Carries `hold_seconds` so far. |
| `call.handoff_ready` | A rep answered a `handoff` call. Carries the bridge details and the questions to ask. |
| `call.completed` | The call ended with a structured answer: status, reference number, rep name, next step and the call type's details. |
| `call.failed` | The call could not be completed. `data.ended_reason` says why. |
| `call.canceled` | The call was stopped by [Cancel a call](https://daybookhealthcare.com/docs/api-reference/calls/cancel) or by a person in the Daybook app, before it dialed or while it ran. |

---

## Verifying signatures

Check that every Daybook webhook came from Daybook and was not replayed, with signature verification examples in Node, Python and Rust.

Source: https://daybookhealthcare.com/docs/webhooks/verifying-signatures

Daybook signs every webhook the [Standard Webhooks](https://www.standardwebhooks.com) way, so any Standard Webhooks library verifies it. Each request carries three headers:

```text
webhook-id: evt_01JBXK8N3QZ7V2C4D5E6F7G8HJ
webhook-timestamp: 1761748300
webhook-signature: v1,K5oZfzN95Z9UVu1EsfQmfVNQhnkZ2pj9o9NDN/H/pI4=
```

The signature is the base64 HMAC-SHA256 of `{webhook-id}.{webhook-timestamp}.{raw body}`, keyed with your endpoint's secret: the base64 bytes after its `whsec_` prefix. To verify:

1. Base64-decode the secret after its `whsec_` prefix; those bytes are the key.
2. Compute the HMAC over the id, a `.`, the timestamp, a `.`, and the **raw** request body. Parse the JSON only after.
3. Compare it in constant time with each `v1,` value in `webhook-signature` (the header can hold several, separated by spaces).
4. Reject if `webhook-timestamp` is more than 5 minutes from now.

Node:

```javascript
import crypto from "node:crypto";

export function verifyDaybookWebhook(rawBody, headers, secret) {
  const id = headers["webhook-id"];
  const timestamp = headers["webhook-timestamp"];
  const key = Buffer.from(secret.replace(/^whsec_/, ""), "base64");
  const expected = crypto
    .createHmac("sha256", key)
    .update(`${id}.${timestamp}.${rawBody}`)
    .digest();
  const ok = headers["webhook-signature"].split(" ").some((s) => {
    const [version, sig] = s.split(",");
    const got = Buffer.from(sig ?? "", "base64");
    return version === "v1" && got.length === expected.length && crypto.timingSafeEqual(got, expected);
  });
  if (!ok || Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) {
    throw new Error("invalid Daybook webhook");
  }
  return JSON.parse(rawBody);
}
```

Python:

```python
import base64, hashlib, hmac, json, time

def verify_daybook_webhook(raw_body: bytes, headers, secret: str) -> dict:
    msg_id, timestamp = headers["webhook-id"], headers["webhook-timestamp"]
    key = base64.b64decode(secret.removeprefix("whsec_"))
    signed = f"{msg_id}.{timestamp}.".encode() + raw_body
    expected = base64.b64encode(hmac.new(key, signed, hashlib.sha256).digest()).decode()
    sigs = [s[3:] for s in headers["webhook-signature"].split(" ") if s.startswith("v1,")]
    if not any(hmac.compare_digest(expected, s) for s in sigs) or abs(time.time() - int(timestamp)) > 300:
        raise ValueError("invalid Daybook webhook")
    return json.loads(raw_body)
```

Rust:

```rust
use base64::{engine::general_purpose::STANDARD, Engine};
use hmac::{Hmac, Mac};
use sha2::Sha256;

pub fn verify(
    raw_body: &[u8],
    id: &str,
    timestamp: &str,
    signature: &str,
    secret: &str,
    now: i64,
) -> Result<(), &'static str> {
    let key = STANDARD
        .decode(secret.strip_prefix("whsec_").unwrap_or(secret))
        .map_err(|_| "bad secret")?;
    let ts: i64 = timestamp.parse().map_err(|_| "bad timestamp")?;
    if (now - ts).abs() > 300 { return Err("stale"); }
    for candidate in signature.split(' ') {
        let Some(("v1", sig)) = candidate.split_once(',') else { continue };
        let Ok(sig) = STANDARD.decode(sig) else { continue };
        let mut mac = Hmac::<Sha256>::new_from_slice(&key).map_err(|_| "bad secret")?;
        mac.update(format!("{id}.{timestamp}.").as_bytes());
        mac.update(raw_body);
        if mac.verify_slice(&sig).is_ok() { return Ok(()); }
    }
    Err("bad signature")
}
```

Frameworks that parse JSON before your handler runs change the bytes. Read the raw body: `express.raw()`, `request.get_data()`, or your framework's equivalent.

### Rolling a secret

Open the endpoint in **Developers → Webhooks** in the Daybook app and choose **Roll secret**. The new `whsec_` secret is shown once and signs every delivery from then on, so deploy it right away, then check the endpoint with **Send test event**.

---

## Deliveries and testing

The delivery log Daybook keeps for each webhook endpoint, what counts as a failed delivery, and how to send a signed test event to check your handler.

Source: https://daybookhealthcare.com/docs/webhooks/deliveries

### Delivery log

Daybook records every delivery: the event id and type, your response status, how long it took, and whether it succeeded. A `2xx` within 10 seconds succeeds; any other status, a refused connection or no answer in that time fails. Request and response bodies are not kept. Open an endpoint in **Developers → Webhooks** in the Daybook app to see its last 50 deliveries.

### Testing

Choose **Send test event** on an endpoint's page, or call [Send a test event](https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/test). Daybook sends one `webhook.test` event at once, signed with the endpoint's current secret, and adds the delivery to the log. A test event is sent even while the endpoint is disabled.

### Managing endpoints

**Disable** stops sending events to an endpoint and **Enable** starts again. **Roll secret** replaces the signing secret (see [Rolling a secret](https://daybookhealthcare.com/docs/webhooks/verifying-signatures)). **Delete** removes the endpoint.

---

## Model Context Protocol

Give Claude, Cursor or your own AI agents Daybook as MCP tools: claims, payer calls, denials and remits, with the same permissions and audit trail as the app.

Source: https://daybookhealthcare.com/docs/mcp

Daybook runs an MCP server with the same operations as the API. Connect Claude, Claude Code, Cursor or your own agent and it can read your worklist, open a claim and its history, read what a payer said on a call, start the next call, read a denial or a remit, draft an appeal and record what was done, with the same permissions and audit trail as a person in the Daybook app.

```text
https://mcp.daybookhealthcare.com/mcp
```

### What an agent can do

- [Work the list](https://daybookhealthcare.com/docs/mcp/tools#start-here): Read today's worklist and home page, plan a shift, and record each item as finished, followed up or handed off.
- [Call the payer](https://daybookhealthcare.com/docs/mcp/payer-calls): Start a payer call from Claude, then read the answer, the reference number and the transcript.
- [Follow a claim](https://daybookhealthcare.com/docs/mcp/tools#claims): Open a claim with its lines, edits and denial, read its timeline, and check its status with the payer.
- [Work denials and remits](https://daybookhealthcare.com/docs/mcp/tools#denials-remits-and-payments): Read the denial's codes and deadline, the flagged payments and the remit lines, and draft the appeal.

### Connect in a minute

#### 1. Make a token

In the Daybook app, open **Profile → AI assistants**, name the token after the app that will use it ("Claude on my laptop") and choose **Add token**. It is shown once; copy it then.

#### 2. Add the server

Claude Code:

```bash
claude mcp add --transport http daybook https://mcp.daybookhealthcare.com/mcp \
  --header "Authorization: Bearer rcm_mcp_..."
```

Claude:

```text
Settings → Connectors → Add custom connector, then paste:

https://mcp.daybookhealthcare.com/mcp/rcm_mcp_...
```

Cursor:

```json
{
  "mcpServers": {
    "daybook": {
      "url": "https://mcp.daybookhealthcare.com/mcp",
      "headers": { "Authorization": "Bearer rcm_mcp_..." }
    }
  }
}
```

#### 3. Ask

*What is on my worklist today, and what should I start with?* Every client, Claude Desktop and VS Code included, is in [Connect a client](https://daybookhealthcare.com/docs/mcp/connect).

### Try it

*Check the status of claim A-20817-1 with Keystone. If it's still pending, tell me what the payer said on the last call.*

The agent calls `check_claim_status`, sees `pending`, then reads the claim's last payer call with `get_call` and reports the rep's answer and reference number. If the claim still needs a call, it goes on to `start_call` with `call_type: claim_status` ([Payer calls from Claude](https://daybookhealthcare.com/docs/mcp/payer-calls)).

More to ask:

- *Why was claim CLM-10234 denied, and is there still time to appeal?*
- *Which payments came in under the contracted rate this week?*
- *Which calls this week ended with the payer saying the claim is in process?*
- *I called the payer on that item and they are reprocessing it. Record it and follow up Friday.*

### Where it fits

|  | Use it for | Credential |
| --- | --- | --- |
| **MCP** | A person asking in Claude, Cursor or another AI app, or an agent you run | An assistant token, or your account's secret key ([Credentials](https://daybookhealthcare.com/docs/mcp/connect#credentials)) |
| **[API](https://daybookhealthcare.com/docs/api-reference)** | Your systems asking from code, at volume, with your own ids | Your account's secret key |
| **[Webhooks](https://daybookhealthcare.com/docs/webhooks)** | Hearing back without asking, a call or a check started from MCP included | A signing secret per endpoint |
| **Ask Daybook** | Asking inside the Daybook app, over the same tools | Your session in the app |

> Portal changes and posting approvals still wait for a person. An agent can ask; it can't approve its own request. See [Permissions and safety](https://daybookhealthcare.com/docs/mcp/permissions).

### Next steps

- [Connect a client](https://daybookhealthcare.com/docs/mcp/connect): Tokens, and the set-up for each AI app.
- [Tools](https://daybookhealthcare.com/docs/mcp/tools): Every tool, what it reads or does, and its API equivalent.
- [Playbooks](https://daybookhealthcare.com/docs/mcp/playbooks): Ready-made prompts: work a denial, plan a shift, post a remit.
- [A Claude agent that works your AR list](https://daybookhealthcare.com/docs/use-cases/mcp-ar-agent): A use case with a prompt that builds it.

---

## Connect a client

Add Daybook's MCP server to Claude, Claude Desktop, Claude Code, Cursor, VS Code or the Claude Agent SDK, with an assistant token that acts as you.

Source: https://daybookhealthcare.com/docs/mcp/connect

Daybook's MCP server speaks streamable HTTP at one URL. Every client sends a credential with each request; Daybook takes the workspace and the person from it, so there is nothing else to configure.

```text
https://mcp.daybookhealthcare.com/mcp
```

### Credentials

| Credential | Looks like | Acts as | Made in |
| --- | --- | --- | --- |
| Assistant token | `rcm_mcp_…` | The person who made it, with only what their role opens | **Profile → AI assistants** in the Daybook app, by each person for themselves |
| Secret key | `sk_test_…`, `sk_live_…` | Your account, like an API request ([Authentication](https://daybookhealthcare.com/docs/authentication)) | **Developers → API keys**, by the owner or anyone who manages integrations |

Use an assistant token for a person's own AI app: what Claude does shows under that person's name. Use a secret key for an agent that runs on your servers with no person behind each request. Make one token per app, so revoking the laptop leaves the phone working. A token is shown once and Daybook keeps only its hash; revoke it from the same page and the app using it stops at once.

### Claude Code

```bash
claude mcp add --transport http daybook https://mcp.daybookhealthcare.com/mcp \
  --header "Authorization: Bearer rcm_mcp_..."
```

Add `--scope user` to have it in every project. `/mcp` in Claude Code shows the server and its tools; the [playbooks](https://daybookhealthcare.com/docs/mcp/playbooks) appear as slash commands, such as `/mcp__daybook__work_a_denial`.

### Claude and Claude Desktop

Claude takes a custom connector by URL alone, so the token goes in the URL as its last path segment.

#### 1. Open the connectors

In Claude, on the web or in the desktop app, open **Settings → Connectors** and choose **Add custom connector**.

#### 2. Paste the URL with your token

```text
https://mcp.daybookhealthcare.com/mcp/rcm_mcp_...
```

#### 3. Turn it on in a chat

Open the tools menu in a chat and switch Daybook on. Claude asks before it runs a tool that writes, unless you allow it always.

A URL with a token in it is a password and can appear in request logs, so give it a token of its own. To keep the token out of the URL in Claude Desktop, bridge with `mcp-remote` in `claude_desktop_config.json` instead:

claude_desktop_config.json:

```json
{
  "mcpServers": {
    "daybook": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.daybookhealthcare.com/mcp",
               "--header", "Authorization: Bearer ${DAYBOOK_TOKEN}"],
      "env": { "DAYBOOK_TOKEN": "rcm_mcp_..." }
    }
  }
}
```

### Cursor

Add the server to `~/.cursor/mcp.json`, or to `.cursor/mcp.json` in one project:

```json
{
  "mcpServers": {
    "daybook": {
      "url": "https://mcp.daybookhealthcare.com/mcp",
      "headers": { "Authorization": "Bearer rcm_mcp_..." }
    }
  }
}
```

### VS Code

Add it to `.vscode/mcp.json`; VS Code asks for the token once and keeps it in its secret store:

```json
{
  "inputs": [
    { "type": "promptString", "id": "daybook-token", "description": "Daybook assistant token", "password": true }
  ],
  "servers": {
    "daybook": {
      "type": "http",
      "url": "https://mcp.daybookhealthcare.com/mcp",
      "headers": { "Authorization": "Bearer ${input:daybook-token}" }
    }
  }
}
```

### Your own agent

An agent you run, on the Claude Agent SDK or any MCP client library, connects the same way with a bearer header. On a server, use a secret key from your secrets manager.

TypeScript:

```typescript
import { query } from "@anthropic-ai/claude-agent-sdk";

for await (const message of query({
  prompt: "Work the denials queue: for each claim, say why it was denied and the next step.",
  options: {
    mcpServers: {
      daybook: {
        type: "http",
        url: "https://mcp.daybookhealthcare.com/mcp",
        headers: { Authorization: `Bearer ${process.env.DAYBOOK_API_KEY}` },
      },
    },
    allowedTools: ["mcp__daybook__worklist", "mcp__daybook__get_claim", "mcp__daybook__list_denials"],
  },
})) {
  if (message.type === "result" && message.subtype === "success") console.log(message.result);
}
```

Python:

```python
import asyncio, os
from claude_agent_sdk import ClaudeAgentOptions, ResultMessage, query

options = ClaudeAgentOptions(
    mcp_servers={
        "daybook": {
            "type": "http",
            "url": "https://mcp.daybookhealthcare.com/mcp",
            "headers": {"Authorization": f"Bearer {os.environ['DAYBOOK_API_KEY']}"},
        }
    },
    allowed_tools=["mcp__daybook__worklist", "mcp__daybook__get_claim", "mcp__daybook__list_denials"],
)

async def main():
    prompt = "Work the denials queue: for each claim, say why it was denied and the next step."
    async for message in query(prompt=prompt, options=options):
        if isinstance(message, ResultMessage):
            print(message.result)

asyncio.run(main())
```

### Other clients

A client that takes a header sends `Authorization: Bearer <token>` to the URL. A client that takes only a URL uses the token as the last path segment, as Claude does.

### When it does not connect

| You see | What it means |
| --- | --- |
| `401 unauthorized` | No token, a revoked one, or a mistyped one. Make a new token in **Profile → AI assistants**. |
| "make a new one" | The token is from before workspaces and names none. Make a new token. |
| A tool answers that you may not see it | Your role does not open that page in the Daybook app. The token can do what you can, no more. |

---

## Tools

Every tool on Daybook's MCP server by area, from the worklist and claims to payer calls, eligibility, denials and remits, with its API equivalent.

Source: https://daybookhealthcare.com/docs/mcp/tools

Each tool reads or acts as the credential that called it ([Credentials](https://daybookhealthcare.com/docs/mcp/connect#credentials)). Tools that read are marked read-only, so a client can run them without asking; tools that act ask first in Claude and Cursor unless you allow them always. Money comes back in dollars beside the cents, so the model never does the arithmetic.

### Start here

| Tool | Does | Kind |
| --- | --- | --- |
| `whoami` | Who is signed in, who they act as, the practice in view and today's date | Reads |
| `home` | The start-of-day summary: queue counts, what is due, what changed | Reads |
| `worklist` | Open work items, by view, queue, focus, owner, practice or search | Reads |
| `record_work` | Record what was done on a work item and finish it, set a follow-up or hand it off | Writes |

### Claims

| Tool | Does | Kind | API equivalent |
| --- | --- | --- | --- |
| `get_claim` | One claim: lines, payer, status, balance, denial and edits | Reads |  |
| `claim_timeline` | Everything that happened to a claim, oldest first: acknowledgments, status answers, calls, remits, notes | Reads |  |
| `check_claim_status` | Ask the payer now, over 276/277 | Acts | [Check claim status](https://daybookhealthcare.com/docs/api-reference/claim-status/create-check) |
| `add_claim_note` | Add a note to a claim, under your name | Writes |  |
| `submissions` | Submissions grouped for triage, or the batches by stage | Reads |  |
| `list_documents`, `get_document` | Charge documents received for coding, and their lines | Reads |  |

### Payer calls

| Tool | Does | Kind | API equivalent |
| --- | --- | --- | --- |
| `list_calls` | The payer calls Daybook placed and what each payer answered, newest first, filtered by answer | Reads | [List calls](https://daybookhealthcare.com/docs/api-reference/calls/list) |
| `get_call` | One payer call, claim by claim, with its reference number and transcript | Reads | [Retrieve a call](https://daybookhealthcare.com/docs/api-reference/calls/get) |
| `start_call` | Call a payer and wait for a structured answer | Acts | [Start a call](https://daybookhealthcare.com/docs/api-reference/calls/create) |
| `ivr_maps` | Each payer's phone tree, as Daybook's voice agent walks it | Reads |  |

### Portals, eligibility and patients

| Tool | Does | Kind | API equivalent |
| --- | --- | --- | --- |
| `start_portal_task` | Run a portal lookup or upload | Acts | [Start a portal task](https://daybookhealthcare.com/docs/api-reference/portal-tasks/create) |
| `check_eligibility` | 270/271 eligibility and benefits | Acts | [Check eligibility](https://daybookhealthcare.com/docs/api-reference/eligibility/create-check) |
| `eligibility_checks` | Recent eligibility checks and their answers | Reads |  |
| `list_patients`, `get_patient` | Patients by display name, with coverages, claims, authorizations and checks | Reads |  |
| `list_authorizations`, `get_authorization` | Prior authorizations: units approved and used, dates, state, and the claims they cover | Reads |  |

### Denials, remits and payments

| Tool | Does | Kind | API equivalent |
| --- | --- | --- | --- |
| `list_denials` | Denials with CARC and RARC codes, category, state and appeal deadline | Reads |  |
| `get_denial` | One denial's cause and next step | Reads | [Retrieve a denial](https://daybookhealthcare.com/docs/api-reference/denials/get) |
| `draft_appeal` | Draft an appeal letter for a person to send | Writes | [Draft an appeal](https://daybookhealthcare.com/docs/api-reference/appeals/create) |
| `list_underpayments` | Payments flagged as under the expected amount | Reads |  |
| `list_remittances` | Remittances (ERAs) received | Reads |  |
| `get_remittance` | One remittance with its claim lines, adjustments and proposed posting | Reads | [Retrieve a remit](https://daybookhealthcare.com/docs/api-reference/remits/get) |

### Enrollment and credentialing

| Tool | Does | Kind | API equivalent |
| --- | --- | --- | --- |
| `list_enrollments` | Payer enrollments and their state | Reads |  |
| `submit_enrollment` | Start an ERA or EFT enrollment | Acts | [Submit an enrollment](https://daybookhealthcare.com/docs/api-reference/enrollments/create) |
| `credentialing` | Providers' credentials, or payer credentialing applications | Reads |  |
| `get_credentialing_sheet` | One provider's or application's sheet | Reads |  |

### Practices, payers and contracts

| Tool | Does | Kind |
| --- | --- | --- |
| `list_practices`, `get_practice` | The firm's practices: profile, onboarding, fee terms and contract rates | Reads |
| `list_clients`, `get_client` | The practices in your scope | Reads |
| `list_payers`, `get_payer` | Payers with limits, routes and phone lines, and one payer's sheet | Reads |
| `fee_schedule` | Contract rates by payer, practice and code | Reads |

### The firm

| Tool | Does | Kind |
| --- | --- | --- |
| `kpis` | The report measures, or one measure in detail | Reads |
| `activity`, `get_agent_run` | What Daybook's agents did, and one run step by step | Reads |
| `automation_rules` | The firm's [rules](https://daybookhealthcare.com/docs/worklists-and-rules) | Reads |
| `list_firm_playbooks`, `get_firm_playbook` | The firm's own playbooks by category | Reads |
| `settings` | The team, rules, connections or audit log page | Reads |
| `trust` | The safeguards Daybook keeps | Reads |
| `vocabulary` | The words the firm uses for its codes | Reads |

A tool with no API equivalent reads what the Daybook app shows on the page of the same name.

---

## Playbooks

Ready-made prompts on Daybook's MCP server: work a denial, chase a flagged payment, post a remittance, check a claim and plan a shift.

Source: https://daybookhealthcare.com/docs/mcp/playbooks

A playbook is a prompt the server hands your AI app: the steps, the tools to use in order, and what the answer must hold. Pick one and fill in the claim; the agent does the rest. In Claude Code and Cursor they are slash commands, and in Claude they are in the **+** menu under Daybook.

| Playbook | Use | Takes |
| --- | --- | --- |
| `work_a_denial` | Why a claim was denied, what to do next, and the note to record | `claim`, and `payer` if you know it |
| `chase_underpayment` | Lay out one flagged payment and draft the reconsideration request a biller would send | `claim` |
| `post_remittance` | Go through one remittance: what posted, what waits for review, and what to do with each exception | `remittance`: its id, trace number or payer |
| `check_claim_status` | Where one claim stands, from its acknowledgments, status answers and remits on file | `claim` |
| `plan_my_shift` | What to work on this shift, in order, from your worklist and home page | `queue`, optional |

### Running one

Claude Code:

```text
/mcp__daybook__work_a_denial CLM-10234 Meridian Health
```

`work_a_denial` opens the claim with `get_claim`, reads its history with `claim_timeline`, finds the denial in `list_denials`, and answers with the codes and their root cause, the amount and the appeal deadline, what was already tried, the next step, and the note it would record. It records the note only when you say so.

The `check_claim_status` playbook reads what is already on file; the `check_claim_status` tool asks the payer again over 276/277. Ask for a fresh check when the last answer is old.

### What every playbook holds to

- Only figures, codes and trace numbers the tools returned. No outcome the payer has not given.
- Neutral words: a payment is "flagged" or "paid differently", never "underpaid" or "owed".
- Nothing recorded unless you ask. Posting itself stays in the remit inbox in the Daybook app.

### Your firm's own playbooks

The playbooks your firm writes in the Daybook app (how you work a CO-197, who you call at Bayline) are readable by any agent through `list_firm_playbooks` and `get_firm_playbook`, so Claude follows your way of working, not a generic one. A playbook to add to Daybook's own list: tell your Daybook contact.

---

## Payer calls from Claude

Connect Daybook's voice agent to Claude: start a payer call from a chat, read the answer, reference number and transcript, and record it on the claim.

Source: https://daybookhealthcare.com/docs/mcp/payer-calls

Daybook's voice agent calls the payer, works the phone tree, waits on hold and asks the rep your questions. Over MCP, Claude can start that call, read what the payer said, and record the outcome, from the same chat where you asked about the claim. It is the [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls) workflow, with Claude as the one asking.

### In a chat

*Claim A-20817-1 with Bayline has been in process for 40 days. Call them, ask for the expected pay date, and record what they say.*

#### 1. Claude checks the claim

`get_claim` and `claim_timeline`: the last status answer and any earlier call, so it does not call about something the payer already answered this week.

#### 2. Claude starts the call

`start_call` with the claim, `call_type: claim_status` and your extra question. Claude asks you before it dials unless you allowed the tool always. The call is gated as every call is: the firm's owner has confirmed Daybook as billing agent, a call script fits the claim's step, and the payer's line is linked.

#### 3. Daybook works the call

Phone tree, hold, rep. Watch it in **Switchboard → Live calls** in the Daybook app, where anyone allowed to control the call can tell the agent something, take the call over or hang up.

#### 4. Claude reads the answer

`start_call` waits for the structured answer: status, reference number, rep name, next step and the call type's details. Claude can read the call again at any time with `get_call`.

#### 5. Claude records it

`record_work` on the work item, with a follow-up date from the rep's answer, or `add_claim_note`. A completed call with a reference number also moves the claim in Daybook to what the payer said.

### Reading calls

| Ask | Tool |
| --- | --- |
| *What did Keystone say about A-20817-1?* | `get_call`: the answer claim by claim, the reference number and the transcript turns, with the phone tree, the hold and any operator notes |
| *Which calls this week ended in a denial?* | `list_calls`, filtered by what the payer answered |
| *How do you reach claims at Meridian?* | `ivr_maps`: the payer's phone tree as the voice agent walks it |
| *Which payers have no line set up?* | `list_payers`: each payer's phone lines |

### Calls Claude starts are calls like any other

They are in **Payer calls** in the Daybook app with the transcript, they send the `call.*` [webhook events](https://daybookhealthcare.com/docs/webhooks/event-types#payer-call-events) to your endpoints, and they count toward your usage. Your ticketing integration hears about a call Claude started the same way it hears about one your queue started. In a sandbox they are real calls through the same voice agent, with events in `mode: test`.

### What stays in the app or the API

| Operation | Where |
| --- | --- |
| Tell the agent something mid-call | **Live calls**, or [Tell the agent something](https://daybookhealthcare.com/docs/api-reference/calls/instruct) |
| Cancel a call | **Live calls**, or [Cancel a call](https://daybookhealthcare.com/docs/api-reference/calls/cancel) |
| Take the line, press keys, listen in | **Live calls**, with a softphone in the browser |
| Hand a live rep to a biller | `mode: handoff` on [Start a call](https://daybookhealthcare.com/docs/api-reference/calls/create) |
| Repeat a call until the status moves | `schedule` on [Start a call](https://daybookhealthcare.com/docs/api-reference/calls/create) |
| Payer lines, phone trees, call scripts | **Switchboard** in the Daybook app |

---

## Permissions and safety

What an AI agent connected to Daybook can see and do, what it never sees, what waits for a person, and how its work is recorded and revoked.

Source: https://daybookhealthcare.com/docs/mcp/permissions

An agent connected to Daybook is a person's assistant or an account's integration, never a new kind of user. It can do what its credential can, no more, and everything it does is on the record under that credential.

### It acts as you

An assistant token reads as the person who made it: only the practices, pages and actions their role opens in the Daybook app. A biller's Claude sees a biller's worklist; it cannot reach team settings the biller cannot. A secret key acts as the account, as an API request does.

### What it never sees

- A patient's birth date, member ids or full identity. Patients are shown by display name.
- A raw 835, 277CA or 999 file. Tools return what Daybook read from them.
- Another workspace's data. A token names its workspace, and an id from another answers as not found.
- Assistant tokens. A token cannot reach the page that makes them.

### What waits for a person

Portal changes and posting approvals wait for a person in the Daybook app. An agent can ask; it can't approve its own request. Writes that only record, such as a claim note or a work record, go through at once. Claude and Cursor ask before every tool that acts or writes, unless you allow it always.

### On the record

- Notes and work records show on the claim and the work item under your name.
- Calls, checks and portal tasks an agent starts are in the Daybook app with everything else, and send the same webhooks.
- Making and revoking a token is in **Settings → Audit log**. **Profile → AI assistants** shows when each token was last used.
- A write carries a request id, so a client that retries records it once.

### Revoking access

Revoke a token in **Profile → AI assistants**; the app using it stops at once. Revoke a secret key in **Developers → API keys**.

---

## Build with AI

Daybook's docs for your AI assistant: every page as Markdown, llms.txt, Copy page and Ask AI, the OpenAPI spec, and use case prompts.

Source: https://daybookhealthcare.com/docs/mcp/build-with-ai

MCP lets an agent use Daybook. To have an assistant write code against Daybook, give it the docs. Every page is built to be read by one.

| What | Where | Use it for |
| --- | --- | --- |
| Copy page | The button beside each page's title | The page as Markdown on your clipboard, to paste into a chat |
| Ask AI | The menu beside Copy page | Claude, ChatGPT or Cursor opened with a prompt to read that page |
| Any page as Markdown | Add `.md` to its URL: `/docs/quickstart.md` | Pointing a coding agent at one page |
| [llms.txt](https://daybookhealthcare.com/llms.txt) | `/llms.txt` | A short index of the site and the docs |
| [llms-full.txt](https://daybookhealthcare.com/llms-full.txt) | `/llms-full.txt` | Every docs page in one file, in the sidebar's order |
| [OpenAPI](https://daybookhealthcare.com/docs/openapi.json) | `/docs/openapi.json` | The API reference as a spec, for client generators |
| [Use case prompts](https://daybookhealthcare.com/docs/use-cases) | Each use case's **Copy prompt** | A build brief that links the pages it needs, ready for Claude, Codex, Cursor or ChatGPT |

### In Claude Code

Give Claude Code the docs and the server together: it reads the pages it needs and checks its work against your sandbox.

```bash
claude mcp add --transport http daybook https://mcp.daybookhealthcare.com/mcp \
  --header "Authorization: Bearer rcm_mcp_..."

claude "Read https://daybookhealthcare.com/docs/workflows/payer-calls.md and \
https://daybookhealthcare.com/docs/webhooks/verifying-signatures.md, then write \
a webhook handler that writes call.completed onto our tickets. Use the daybook \
tools to look at a real call in our sandbox first."
```

---

## Explore APIs by workflow

Find the Daybook APIs and webhook events you need by workflow: reaching payers, getting providers set up, and following a claim until it is paid.

Source: https://daybookhealthcare.com/docs/workflows

- [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls.md): Call the payer, work the phone tree, wait on hold, and get a structured answer back.
- [Payer portals](https://daybookhealthcare.com/docs/workflows/payer-portals.md): Sign in to payer portals, run a defined set of steps, and read the result back.
- [ERA and EFT enrollment](https://daybookhealthcare.com/docs/workflows/enrollment.md): Enroll every provider with every payer for electronic remits and payments, and track it to approval.
- [Eligibility and benefits](https://daybookhealthcare.com/docs/workflows/eligibility.md): Check coverage and benefits over 270/271 in real time, one at a time or by the thousand.
- [Claim status](https://daybookhealthcare.com/docs/workflows/claim-status.md): 276/277 claim status checks in real time and at volume, kicked off by your own rules.
- [Remittance and posting](https://daybookhealthcare.com/docs/workflows/remittance.md): Pull 835s, match them to claims and deposits, and propose the posting entries for each payment.
- [Denials and appeals](https://daybookhealthcare.com/docs/workflows/denials-and-appeals.md): Read CARC and RARC codes, sort each denial by cause, trigger the next step, and draft the appeal.

---

## Payer calls

Integrate payer phone calls with the Daybook API: start a call from your queue with your ids, follow its lifecycle, and get the structured answer by webhook.

Source: https://daybookhealthcare.com/docs/workflows/payer-calls

> "What did the payer say, and what do we do next?"

The **Payer calls** workflow phones payers for you. Daybook's voice agent works through the phone tree, waits on hold, and when a rep picks up it either asks your questions itself or brings your biller onto the line. Every call ends in a structured answer with the payer's reference number, written to the claim and sent to your system, not a note someone has to type up. This page is the integration guide: how a work queue, a CRM or an internal dashboard hands Daybook a claim to call about, follows the call, receives the answer and closes the loop.

### At a glance

- **Workflow:** Payer calls
- **Stage:** Any time EDI or the portal can't answer
- **Primary users:** AR follow-up, denial and eligibility teams, and the engineers wiring their queues to Daybook
- **Core question:** What did the payer say, and what do we do next?
- **Call types:** Claim status · Eligibility · Prior auth · Appeal status · Payment trace
- **Lifecycle:** queued · dialing · navigating · on_hold · with_rep · completed, failed or canceled
- **Comes back as:** Status · Reference number · Rep name · Next step · Call-type details, with your metadata echoed
- **API:** POST /v1/calls · GET /v1/calls · GET /v1/calls/{id} · cancel · instruct · transcript · call.* webhooks · MCP start_call
- **In a sandbox:** Real calls through the same voice agent, behind the same gates. Events carry mode test

### What this workflow enables

- Put a payer call on a claim from your own queue, with your ids on it, and get the answer back under the same ids.
- Map a payer's phone tree once and save it, so later calls go straight to the right option.
- Hand a live rep to a biller with the questions ready, or let Daybook handle the call.
- Follow the call as it moves: queued, dialing, phone tree, hold, rep, done.
- Repeat a call on a schedule, such as every 5 days until a pending claim moves, and cancel a call your queue no longer needs.
- Tell the agent something while it is on the line, and keep the transcript beside the answer.
- Write status, reference number, rep name and next step straight into your ticket, claim or CRM record.

### Typical flow

1. **Pick the work.** Your queue decides what needs a call: a claim silent for 30 days after the 277 said nothing useful, a denial your rules say to challenge by phone, a payment to trace. Pull the claim, patient and provider from your record, and keep your own ids ready: the account, the ticket, the work item. They travel with the call as `metadata` and come back on every event about it.
2. **Start the call.** `POST /v1/calls` with the payer, the call type, the claim, patient and provider, and `metadata` holding your ids. Send an `Idempotency-Key`, such as the ticket id and attempt number, so a retry after a timeout never dials twice. The response is the call in status `queued` with an id prefixed `call_`; store it on your ticket.
3. **Daybook works the phone tree.** It presses the keys and enters the ids the menu asks for, following the payer's saved phone tree where there is one and learning it the first time. The call moves through `dialing` to `navigating`, and you receive `call.started`.
4. **Hold.** Daybook waits. `call.on_hold` carries the hold time so far, and `GET /v1/calls/{id}` shows `on_hold` with `hold_seconds`. In the Daybook app the call sits under **Switchboard → Live calls** with its transcript as it happens.
5. **A rep picks up.** The call is `with_rep`. In `autonomous` mode Daybook asks the call script's questions and reads the answers back. In `handoff` mode it rings the biller named in `handoff.phone` and sends `call.handoff_ready` with the questions to ask. From Live calls, anyone allowed to control the call can tell the agent something, take the call over or hang up.
6. **Structured answer and write-back.** `call.completed` carries the status, reference number, rep name, next step and the call type's details, with your `metadata` echoed. Verify the signature, record the event id, update your ticket and return `2xx`. A call that could not finish sends `call.failed` instead. A completed call with a reference number also moves the claim in Daybook to what the payer said: paid, denied, pended or in process.

Example integration, curl:

```bash
# 1. A queue item that needs a call becomes one request. Your ids ride along as metadata,
#    In your code make the Idempotency-Key the ticket and attempt (the Node tab does); here a fresh UUID.
curl https://api.daybookhealthcare.com/v1/calls \
  -H "Authorization: Bearer $DAYBOOK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "payer": "bayline",
    "call_type": "claim_status",
    "claim": { "patient_control_number": "A-10442-1", "date_of_service": "2026-09-14" },
    "patient": { "first_name": "Jordan", "last_name": "Sample",
                 "date_of_birth": "1980-01-01", "member_id": "W000000001" },
    "provider": { "npi": "1999999984" },
    "metadata": { "account": "A-10442", "ticket": "TCK-55821" }
  }'
# -> { "id": "call_01JBX8M4Q2T7", "status": "queued", ... }  store the id on the ticket

# 2. Where does it stand? Poll if you must; the answer itself arrives as call.completed.
curl https://api.daybookhealthcare.com/v1/calls/call_01JBX8M4Q2T7 \
  -H "Authorization: Bearer $DAYBOOK_API_KEY"
```

Example integration, Node:

```javascript
import express from "express";
import { verifyDaybookWebhook } from "./verify.js";
import { tickets } from "./tickets.js"; // your work queue, CRM or dashboard

const API = "https://api.daybookhealthcare.com/v1";
const auth = { Authorization: "Bearer " + process.env.DAYBOOK_API_KEY, "Content-Type": "application/json" };

// 1. Queue item -> one call. Your ids go in metadata; the idempotency key is the ticket and attempt.
export async function callPayerFor(ticket) {
  const res = await fetch(API + "/calls", {
    method: "POST",
    headers: { ...auth, "Idempotency-Key": "ticket-" + ticket.id + "-call-" + (ticket.callAttempts + 1) },
    body: JSON.stringify({
      payer: ticket.payerId, // "bayline"
      call_type: "claim_status",
      claim: { patient_control_number: ticket.claimId, date_of_service: ticket.dateOfService },
      patient: ticket.patient, // first_name, last_name, date_of_birth, member_id
      provider: { npi: ticket.npi },
      metadata: { account: ticket.accountId, ticket: ticket.id },
    }),
  });
  const call = await res.json(); // status "queued"
  await tickets.update(ticket.id, { daybookCallId: call.id, status: "calling payer" });
}

// 2. The answer arrives as a signed webhook. Verify, acknowledge, then write it back.
const app = express();
app.post("/daybook/webhooks", express.raw({ type: "application/json" }), async (req, res) => {
  const event = verifyDaybookWebhook(req.body, req.headers, process.env.DAYBOOK_WEBHOOK_SECRET);
  res.sendStatus(200);
  if (await tickets.seenEvent(event.id)) return; // a retried delivery carries the same id

  const ticketId = event.data.metadata?.ticket; // the id you sent, echoed back
  if (event.type === "call.completed" && ticketId) {
    const a = event.data.answer;
    await tickets.update(ticketId, {
      status: a.status === "paid" ? "closed" : "needs work",
      payerSaid: a.status,
      reference: a.reference_number,
      rep: a.rep_name,
      nextStep: a.next_step,
      denialReason: a.details?.denial_reason ?? null,
      note: "Payer call " + event.data.id + ": " + a.status + ", ref " + a.reference_number + ". " + a.next_step,
    });
  } else if (event.type === "call.failed" && ticketId) {
    await tickets.update(ticketId, { status: "retry call", note: "Payer call " + event.data.id + " did not complete" });
  }
  await tickets.markEvent(event.id);
});
```

Example integration, Python:

```python
import os, requests
from flask import Flask, request
from verify import verify_daybook_webhook
from tickets import tickets  # your work queue, CRM or dashboard

API = "https://api.daybookhealthcare.com/v1"
AUTH = {"Authorization": "Bearer " + os.environ["DAYBOOK_API_KEY"]}

# 1. Queue item -> one call. Your ids go in metadata; the idempotency key is the ticket and attempt.
def call_payer_for(ticket):
    res = requests.post(
        API + "/calls",
        headers={**AUTH, "Idempotency-Key": f"ticket-{ticket.id}-call-{ticket.call_attempts + 1}"},
        json={
            "payer": ticket.payer_id,  # "bayline"
            "call_type": "claim_status",
            "claim": {"patient_control_number": ticket.claim_id, "date_of_service": ticket.date_of_service},
            "patient": ticket.patient,  # first_name, last_name, date_of_birth, member_id
            "provider": {"npi": ticket.npi},
            "metadata": {"account": ticket.account_id, "ticket": ticket.id},
        },
    )
    call = res.json()  # status "queued"
    tickets.update(ticket.id, daybook_call_id=call["id"], status="calling payer")

# 2. The answer arrives as a signed webhook. Verify, acknowledge, then write it back.
app = Flask(__name__)

@app.post("/daybook/webhooks")
def daybook_webhook():
    event = verify_daybook_webhook(request.get_data(), request.headers, os.environ["DAYBOOK_WEBHOOK_SECRET"])
    if tickets.seen_event(event["id"]):  # a retried delivery carries the same id
        return "", 200
    ticket_id = event["data"].get("metadata", {}).get("ticket")  # the id you sent, echoed back
    if event["type"] == "call.completed" and ticket_id:
        a = event["data"]["answer"]
        tickets.update(
            ticket_id,
            status="closed" if a["status"] == "paid" else "needs work",
            payer_said=a["status"],
            reference=a["reference_number"],
            rep=a["rep_name"],
            next_step=a["next_step"],
            denial_reason=(a.get("details") or {}).get("denial_reason"),
        )
    elif event["type"] == "call.failed" and ticket_id:
        tickets.update(ticket_id, status="retry call")
    tickets.mark_event(event["id"])
    return "", 200
```

### The control surface

Everything an integration can do with a payer call, and what it is called. The last two rows are firm set-up and operator controls, done in the Daybook app.

| Operation | Shape | Notes |
| --- | --- | --- |
| Start a call | [`POST /v1/calls`](https://daybookhealthcare.com/docs/api-reference/calls/create) | Gated the same way everywhere: the firm's owner has confirmed Daybook as billing agent, a call script fits the claim's step, the payer's line is linked. Send an `Idempotency-Key`. |
| List and filter calls | [`GET /v1/calls`](https://daybookhealthcare.com/docs/api-reference/calls/list) | By claim, status, payer, call type, time window or `metadata[key]`. Pages of up to 100. |
| Retrieve a call | [`GET /v1/calls/{id}`](https://daybookhealthcare.com/docs/api-reference/calls/get) | Prefer `call.completed` over polling; it carries the same `answer` and your `metadata`. |
| Cancel a call | [`POST /v1/calls/{id}/cancel`](https://daybookhealthcare.com/docs/api-reference/calls/cancel) | Queued: never dials. Live: the agent says goodbye. Repeating: the series stops. Sends `call.canceled`. |
| Tell the agent something | [`POST /v1/calls/{id}/instruct`](https://daybookhealthcare.com/docs/api-reference/calls/instruct) | Up to 280 characters, never spoken as written; it shows in the transcript as an operator note. |
| Read the transcript | [`GET /v1/calls/{id}/transcript`](https://daybookhealthcare.com/docs/api-reference/calls/transcript) | Turn by turn, with the phone tree, the hold and your notes. |
| Hand off to a biller | `mode: handoff` and `handoff.phone` on start; `call.handoff_ready` | The agent gets through the tree, holds, and rings your biller when a rep answers. Nobody picks up: the call ends as `failed` with the reason. |
| Repeat until the status moves | `schedule` on start; cancel stops the series | Each run is a new call with `repeat_of` the first one and the same metadata. Each run is a real call, in a sandbox too. |
| Hear about it | `call.started`, `call.on_hold`, `call.handoff_ready`, `call.completed`, `call.failed`, `call.canceled` | The same `id` on every retry; your `metadata` echoed on each. |
| Let an agent do it | MCP `list_calls`, `get_call`; `start_call` | Same permissions and audit trail as the API. See [Payer calls from Claude](https://daybookhealthcare.com/docs/mcp/payer-calls). |
| Take over the line, press keys, listen in | Daybook app, Live calls | A takeover needs a person's softphone in the browser; keys and listening are operator controls, not an integration surface. |
| Payer lines, phone trees, voice agents, call scripts | Daybook app, Switchboard area | Firm set-up a lead does once. Not part of the firm API contract; the voice agent's own control plane is behind a credential Daybook holds. |

### Auth, isolation and errors

Every call route takes your firm's key as a bearer token ([Authentication](https://daybookhealthcare.com/docs/authentication)). A key opens one workspace in one environment: `sk_test_` keys see only their sandbox's calls and `sk_live_` keys only their production account's, and a call id from another account answers `404 not_found`, never a hint that it exists. A missing or wrong key is `401 authentication_failed`; a route a key may not use is `403`. Every `POST` takes an `Idempotency-Key`: the same key within 24 hours returns the first answer, the same key with a different body is `409 idempotency_conflict`. Cancel or instruct on a call that has ended is `409 conflict`; a missing field is `400 invalid_request` with `field` naming it. Shapes on [Idempotency and errors](https://daybookhealthcare.com/docs/idempotency-and-errors).

`metadata` is for your ids: account, ticket, queue, work item. Never put a patient's name, date of birth or member id in it; those go in `patient` and `claim`, where Daybook handles them as PHI. Metadata is echoed on every event and will end up in your logs.

### Set it up: a denial queue that calls the payer and writes the answer back

The most common hookup. Your work queue, whether it is a denial worklist, an aged AR report or a task list in your PM system, decides which claims need a payer on the phone. Daybook makes the calls, and the verified answer lands back on the same ticket with the payer's reference number before a biller looks at it. The queue a person works shrinks to the calls that needed a person.

1. **Pick the rule in your queue.** Denials with CARC CO-197 or CO-16 more than five days old and no appeal filed; claims silent 30 days after submission whose 277 said nothing useful. Each is a ticket with the claim, patient and provider at hand.
2. **Start one call per ticket** with `POST /v1/calls`: `call_type` `claim_status`, your extra `questions`, and `metadata` with the ticket, account and queue. The `Idempotency-Key` is the ticket id and the attempt number, so a crashed sweep never dials twice. Store `call.id` on the ticket and mark it "calling payer".
3. **Register a webhook endpoint** for `call.completed`, `call.failed` and `call.canceled` (the [Quickstart](https://daybookhealthcare.com/docs/quickstart) shows how). Verify the signature, return `2xx`, and drop an `id` you have seen.
4. **On `call.completed`**, write `answer.status`, `reference_number`, `rep_name`, `next_step` and the details onto the ticket, then move it: `paid` closes it with the check number for posting to match; `denied` opens the appeal step with the denial reason; `pending` or `in_process` sets a follow-up date; `not_on_file` routes it to resubmission.
5. **On `call.failed` or `call.canceled`**, take the exception path. Count the attempt: under three, let the rule start a new call tomorrow with a new `Idempotency-Key`; at three, assign the ticket to a person with `ended_reason` and the transcript link.
6. **Reconcile nightly** with `GET /v1/calls?metadata[queue]=denials&status=queued,dialing,navigating,on_hold,with_rep`: anything running longer than your ceiling gets a cancel and a person.

Node (Express):

```javascript
import express from "express";
import { verifyDaybookWebhook } from "./verify.js";
import { crm } from "./crm.js"; // your denial queue, CRM or PM system

const API = "https://api.daybookhealthcare.com/v1";
const auth = { Authorization: "Bearer " + process.env.DAYBOOK_API_KEY, "Content-Type": "application/json" };
const MAX_ATTEMPTS = 3;

// 1. The queue rule: denials for a missing authorization, five days old, no appeal filed, no call yet.
export async function sweepDenialQueue() {
  const tickets = await crm.tickets.find({
    queue: "denials", carc: ["CO-197", "CO-16"], olderThanDays: 5, appealFiled: false, daybookCallId: null,
  });
  for (const t of tickets) await startCall(t);
}

// 2. One ticket, one call. The ticket and attempt are the idempotency key, so a crashed sweep never dials twice.
async function startCall(t) {
  const res = await fetch(API + "/calls", {
    method: "POST",
    headers: { ...auth, "Idempotency-Key": "ticket-" + t.id + "-call-" + (t.callAttempts + 1) },
    body: JSON.stringify({
      payer: t.payerId,
      call_type: "claim_status",
      claim: { patient_control_number: t.claimId, payer_claim_number: t.icn, date_of_service: t.dateOfService },
      patient: t.patient, // first_name, last_name, date_of_birth, member_id: PHI goes here, never in metadata
      provider: { npi: t.renderingNpi },
      questions: ["Was the retro authorization request received?"],
      metadata: { ticket: t.id, account: t.accountId, queue: "denials" },
    }),
  });
  if (!res.ok) {
    await crm.tickets.note(t.id, "Daybook refused the call: " + (await res.json()).error.message);
    return;
  }
  const call = await res.json(); // status "queued"
  await crm.tickets.update(t.id, { daybookCallId: call.id, callAttempts: t.callAttempts + 1, status: "calling payer" });
}

// 3. The answer comes back on the same ticket, signed. Verify, acknowledge, then write.
const app = express();
app.post("/daybook/webhooks", express.raw({ type: "application/json" }), async (req, res) => {
  const event = verifyDaybookWebhook(req.body, req.headers, process.env.DAYBOOK_WEBHOOK_SECRET);
  res.sendStatus(200);
  if (await crm.events.seen(event.id)) return; // a retried delivery carries the same id
  const call = event.data;
  const ticketId = call.metadata?.ticket;
  if (!ticketId) return;

  if (event.type === "call.completed") {
    const a = call.answer;
    await crm.tickets.update(ticketId, {
      payerSaid: a.status, reference: a.reference_number, rep: a.rep_name, nextStep: a.next_step,
      payerClaimNumber: call.claim?.payer_claim_number, transcriptUrl: call.transcript_url,
    });
    // 4. Move the ticket by what the payer said.
    if (a.status === "paid") {
      await crm.tickets.close(ticketId, { matchDeposit: a.details?.check_number, paidCents: a.details?.paid_amount_cents });
    } else if (a.status === "denied") {
      await crm.tickets.openStep(ticketId, "file_appeal", { reason: a.details?.denial_reason });
    } else if (a.status === "not_on_file") {
      await crm.tickets.openStep(ticketId, "resubmit");
    } else {
      await crm.tickets.followUp(ticketId, { inDays: 7 }); // pending or in_process
    }
  } else if (event.type === "call.failed" || event.type === "call.canceled") {
    // 5. The exception path: try again tomorrow, then hand the ticket to a person with the reason.
    const t = await crm.tickets.get(ticketId);
    if (event.type === "call.failed" && t.callAttempts < MAX_ATTEMPTS) {
      await crm.tickets.update(ticketId, { status: "retry call", retryAfter: tomorrow() });
    } else {
      await crm.tickets.assign(ticketId, {
        to: "ar-follow-up",
        note: "Daybook could not reach " + t.payerName + " after " + t.callAttempts + " calls: " + call.ended_reason,
      });
    }
  }
  await crm.events.mark(event.id);
});

const tomorrow = () => new Date(Date.now() + 86_400_000).toISOString();
```

curl:

```bash
# 6. Reconcile nightly: what is still running for the denials queue
curl -g "https://api.daybookhealthcare.com/v1/calls?metadata[queue]=denials&status=queued,dialing,navigating,on_hold,with_rep&limit=100" \
  -H "Authorization: Bearer $DAYBOOK_API_KEY"

# A ticket closed by hand before the call went out: stop the call
curl -X POST https://api.daybookhealthcare.com/v1/calls/call_01JBX8M4Q2T7/cancel \
  -H "Authorization: Bearer $DAYBOOK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{ "reason": "Ticket closed by hand; the claim paid on the 835 of 2026-10-30" }'
```

What the firm gets: every denial in the rule is worked the day it qualifies, with the payer's own words and a reference number on the ticket, and billers spend their time on the appeals and the exceptions rather than on hold.

### Set it up: hold the line for a biller and hand the rep over

Some calls need a person: an appeal argument, a contract dispute, a payer that will only speak to the office. Daybook still does the part nobody wants, the phone tree and the hold. When a rep answers, Daybook rings your biller, and your tool pops the ticket with the questions as the call connects.

1. **Start the call with `mode: handoff`** and `handoff.phone`, the biller's number in E.164, plus `name` for your logs. Add the `questions` the biller should cover beyond the call type's standard ones; they ride with the call and come back on `call.handoff_ready`.
2. **On `call.started` and `call.on_hold`**, your dashboard shows "Daybook is holding with Meridian for TCK-61044" with `hold_seconds`, so the biller keeps working.
3. **On `call.handoff_ready`**, a rep is on the line and Daybook is ringing the biller. Pop the ticket on the biller's screen with `handoff.questions` and `handoff.rep_name`; the biller picks up and is talking to a rep who already knows which claim this is.
4. **Nobody picks up** within the ring: the agent says goodbye and the call ends as `failed`, `ended_reason` saying so. Route the ticket back to the queue.
5. **On `call.completed`**, `answer` carries what the agent captured before the handoff, such as the reference number and the rep's name. What the biller learned on the line, they record on the ticket in your tool, or in Daybook's app as a call logged by hand.
6. **The browser alternative:** **Take over** in Live calls opens a softphone for the person watching the call. By API, the handoff is the ring.

Python (Flask):

```python
import os, requests
from flask import Flask, request
from verify import verify_daybook_webhook
from desk import desk  # your dashboard: tickets, billers, screen pops

API = "https://api.daybookhealthcare.com/v1"
AUTH = {"Authorization": "Bearer " + os.environ["DAYBOOK_API_KEY"]}

# 1. Hold the line for a biller: the agent does the phone tree and the hold, then rings them.
def hold_the_line_for(ticket, biller):
    res = requests.post(
        API + "/calls",
        headers={**AUTH, "Idempotency-Key": f"ticket-{ticket.id}-handoff-{ticket.call_attempts + 1}"},
        json={
            "payer": ticket.payer_id,  # "meridian"
            "call_type": "appeal_status",
            "mode": "handoff",
            "handoff": {"phone": biller.phone_e164, "name": biller.name},
            "questions": [
                "Was the appeal received, and which reviewer has it?",
                "What is the decision deadline?",
            ],
            "claim": {"patient_control_number": ticket.claim_id, "payer_claim_number": ticket.icn,
                      "date_of_service": ticket.date_of_service},
            "patient": ticket.patient,  # PHI goes here, never in metadata
            "provider": {"npi": ticket.npi},
            "metadata": {"ticket": ticket.id, "biller": biller.id},
        },
    )
    call = res.json()
    desk.tickets.update(ticket.id, daybook_call_id=call["id"], status="Daybook is calling the payer")

app = Flask(__name__)

@app.post("/daybook/webhooks")
def daybook_webhook():
    event = verify_daybook_webhook(request.get_data(), request.headers, os.environ["DAYBOOK_WEBHOOK_SECRET"])
    if desk.events.seen(event["id"]):
        return "", 200
    call = event["data"]
    ticket_id = call["metadata"]["ticket"]
    biller_id = call["metadata"]["biller"]

    if event["type"] == "call.on_hold":
        # 2. The biller keeps working; the ticket shows the hold ticking.
        desk.tickets.banner(ticket_id, f"Daybook is on hold with the payer, {call['hold_seconds'] // 60} min so far")
    elif event["type"] == "call.handoff_ready":
        # 3. A rep is on the line and the biller's phone is ringing: pop the ticket with the questions.
        desk.screen_pop(biller_id, ticket_id, questions=call["handoff"]["questions"], rep=call["handoff"].get("rep_name"))
    elif event["type"] == "call.completed":
        # 4. What the agent captured before the handoff; the biller records the rest on the ticket.
        a = call["answer"] or {}
        desk.tickets.update(ticket_id, status="worked by biller", reference=a.get("reference_number"),
                            rep=a.get("rep_name"), transcript_url=call["transcript_url"])
        desk.tickets.ask(biller_id, ticket_id, "Record what the payer said on the call")
    elif event["type"] in ("call.failed", "call.canceled"):
        # 5. Nobody picked up the ring, or the payer hung up: back to the queue with the reason.
        desk.tickets.update(ticket_id, status="needs a call", note=f"Handoff did not complete: {call.get('ended_reason')}")
    desk.events.mark(event["id"])
    return "", 200
```

What the firm gets: billers take the calls that need their judgment without the twenty minutes of hold before each, and every handoff is on the record with a transcript up to the moment the rep answered.

### Set it up: recheck a pending claim every five days until it moves

A claim the payer says is in process will move eventually, and someone has to keep asking. A `schedule` on the first call makes Daybook ask every few days and stop on its own when the answer changes; your 835 or 277 can stop it sooner.

1. **Start the first call** with `schedule.repeat_every_days` and `until` `status_changes` (or a date). The response carries `next_run_at`.
2. **Each later run is its own call** with `repeat_of` the first call's id and the same `metadata`, so the handler from the first walkthrough needs no special case. The series stops itself when `answer.status` changes.
3. **Stop it early** with `POST /v1/calls/{id}/cancel` on any call in the series when your remit or claim status check says the claim moved.

```bash
# Start a claim status call that repeats every 5 days until the status changes
curl https://api.daybookhealthcare.com/v1/calls \
  -H "Authorization: Bearer $DAYBOOK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "payer": "keystone",
    "call_type": "claim_status",
    "claim": { "patient_control_number": "A-20817-1", "date_of_service": "2026-09-30" },
    "patient": { "first_name": "Jordan", "last_name": "Sample",
                 "date_of_birth": "1980-01-01", "member_id": "W000000001" },
    "provider": { "npi": "1999999984" },
    "schedule": { "repeat_every_days": 5, "until": "status_changes" },
    "metadata": { "ticket": "TCK-61007", "queue": "silent-claims" }
  }'
# -> "next_run_at": "2026-11-14T14:02:11Z". Every later run is a new call with
#    "repeat_of": "call_01JBX8M4Q2T7" and the same metadata, so your handler needs no special case.

# Your 835 says it paid: stop the series before the next run
curl -X POST https://api.daybookhealthcare.com/v1/calls/call_01JBX8M4Q2T7/cancel \
  -H "Authorization: Bearer $DAYBOOK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{ "reason": "Paid on the 835 of 2026-11-12" }'
```

### Journeys

- **Check a claim by phone:** When the 277 says nothing useful, ask a rep where the claim stands.
- **Recheck until it moves:** Schedule a call every few days until the status changes, then stop.
- **Hand a live rep to a biller:** Skip the hold. Your biller joins only when a person is on the line.
- **Trace a payment:** Get the check or EFT number, amount and date for a claim marked paid.

### Use cases

- [Call the payer from your denial queue](https://daybookhealthcare.com/docs/use-cases/denial-call-queue.md): Every denial a phone call settles gets one, and the rep's answer lands back on the same ticket.
- [Post finished payer calls to Slack](https://daybookhealthcare.com/docs/use-cases/slack-call-alerts.md): 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.
- [A Claude agent that works your AR list](https://daybookhealthcare.com/docs/use-cases/mcp-ar-agent.md): Claude checks each claim, reads the payer's last answer and the denial, and drafts the appeal for a person to approve.
- [Recheck silent claims by phone until they move](https://daybookhealthcare.com/docs/use-cases/silent-claim-recheck.md): Claims with no 276/277 answer get a payer call that repeats every few days and stops once the claim is paid.
- [Catch terminated coverage on open claims](https://daybookhealthcare.com/docs/use-cases/coverage-watch.md): When a patient's coverage changes, your product flags their open claims and visits, and can call the payer to confirm.

### APIs powering this workflow

- `POST /v1/calls`: [Start a call](https://daybookhealthcare.com/docs/api-reference/calls/create.md)
- `GET /v1/calls`: [List calls](https://daybookhealthcare.com/docs/api-reference/calls/list.md)
- `GET /v1/calls/{id}`: [Retrieve a call](https://daybookhealthcare.com/docs/api-reference/calls/get.md)
- `POST /v1/calls/{id}/cancel`: [Cancel a call](https://daybookhealthcare.com/docs/api-reference/calls/cancel.md)
- `POST /v1/calls/{id}/instruct`: [Tell the agent something](https://daybookhealthcare.com/docs/api-reference/calls/instruct.md)
- `GET /v1/calls/{id}/transcript`: [Read the transcript](https://daybookhealthcare.com/docs/api-reference/calls/transcript.md)

### Events you receive

- `call.started`: Daybook dialed and is working the phone tree. The call is `dialing`, then `navigating`.
- `call.on_hold`: Daybook reached the hold queue. Carries `hold_seconds` so far.
- `call.handoff_ready`: A rep answered a `handoff` call. Carries the bridge details and the questions to ask.
- `call.completed`: The call ended with a structured answer, your metadata echoed.
- `call.failed`: The call could not be completed. `ended_reason` says why.
- `call.canceled`: The call was stopped by [Cancel a call](https://daybookhealthcare.com/docs/api-reference/calls/cancel) or by a person in the Daybook app, before it dialed or while it ran. `ended_reason` carries the reason given.

Example event:

```json
{
  "id": "evt_01JBXM2A4C6E8G0J2M4P6R8T0W",
  "type": "call.completed",
  "created_at": "2026-10-29T14:31:40Z",
  "mode": "live",
  "data": {
    "id": "call_01JBX8M4Q2T7",
    "payer": "bayline",
    "call_type": "claim_status",
    "mode": "autonomous",
    "hold_seconds": 1412,
    "answer": {
      "status": "denied",
      "reference_number": "BHP-4471-0092",
      "rep_name": "Dana",
      "next_step": "Submit a retro authorization, then request reprocessing.",
      "details": {
        "denial_reason": "CO-197 precertification absent"
      }
    },
    "metadata": {
      "account": "A-10442",
      "ticket": "TCK-55821"
    }
  }
}
```

---

## Payer portals

Automate payer portal work with the Daybook API: sign in, run a defined set of steps and read the result back, with an approval where you want one.

Source: https://daybookhealthcare.com/docs/workflows/payer-portals

> "What does the portal show, and can we act on it without a person clicking through?"

The **Payer portals** workflow does the portal work your team does by hand. Daybook signs in, MFA included, runs a defined set of steps and reads the result back as data. Lookups run on their own. Anything that changes something in a portal can be held for a person to approve before it goes through.

### At a glance

- **Workflow:** Payer portals
- **Stage:** Whenever the answer lives in a portal and not in EDI
- **Primary users:** Billers, payment posters, denial teams
- **Core question:** What does the portal show, and can we act on it?
- **Tasks:** Remit lookup · Claim lookup · Appeal status · Attachment upload · Overpayment lookup
- **Safety:** Changes held for approval, every page captured as evidence
- **Consumption options:** API · Webhooks · MCP

### What this workflow enables

- Pull a remit or claim detail from a portal when the 835 never arrived.
- Check appeal status without a biller signing in to each payer.
- Upload attachments the payer asked for.
- Look up overpayment requests before they turn into recoupments.
- Approve any change before Daybook submits it, with a screenshot of exactly what will be sent.

### Typical flow

1. **Start the task.** `POST /v1/portal-tasks` with the payer, the task and the claim or provider it is about.
2. **Daybook signs in.** It uses the provider's portal account, handles MFA, and picks the portal that answers the task for that payer.
3. **Approval, if it changes something.** For tasks that change something, Daybook stops and sends `portal_task.approval_required` with a screenshot of the screen as it will be submitted.
4. **You approve.** `POST /v1/portal-tasks/{id}/approve`, from your system or from the Daybook app.
5. **Result.** `portal_task.completed` carries what Daybook read back, plus every page it captured along the way.

### Journeys

- **Find a missing remit:** The payment hit the bank but no 835 came. Pull it from the portal.
- **Check an appeal:** See where an appeal stands without signing in.
- **Send an attachment:** Upload what the payer asked for, after a person approves it.
- **Catch an overpayment:** Read overpayment letters before the payer takes the money back.

### Use cases

- [Find a missing remit in the payer portal](https://daybookhealthcare.com/docs/use-cases/portal-remit-lookup.md): When a payment shows up with no 835, Daybook signs in to the portal and brings the remit back.

### APIs powering this workflow

- `POST /v1/portal-tasks`: [Start a portal task](https://daybookhealthcare.com/docs/api-reference/portal-tasks/create.md)
- `GET /v1/portal-tasks/{id}`: [Retrieve a portal task](https://daybookhealthcare.com/docs/api-reference/portal-tasks/get.md)
- `POST /v1/portal-tasks/{id}/approve`: [Approve a portal action](https://daybookhealthcare.com/docs/api-reference/portal-tasks/approve.md)

### Events you receive

- `portal_task.approval_required`: A step would change something in the portal and is waiting on you.
- `portal_task.completed`: The task finished, with its result and evidence.
- `portal_task.failed`: The task could not finish, with the reason.

Example event:

```json
{
  "id": "evt_01JBXN7A4C6E8G0J2M4P6R8T0W",
  "type": "portal_task.approval_required",
  "created_at": "2026-10-29T15:12:03Z",
  "mode": "live",
  "data": {
    "id": "ptask_01JBXB5",
    "payer": "meridian",
    "task": "attachment_upload",
    "pending_action": {
      "summary": "Upload narrative.pdf to claim 2026288000771 as supporting documentation.",
      "screenshot_url": "https://files.daybookhealthcare.com/e/ptask_01JBXB5/confirm?sig=..."
    }
  }
}
```

---

## ERA and EFT enrollment

Enroll every provider with every payer for ERA and EFT with one request each, and track every enrollment to approval through Daybook's webhooks.

Source: https://daybookhealthcare.com/docs/workflows/enrollment

> "Will this payer send us 835s and pay us electronically?"

The **ERA and EFT enrollment** workflow gets providers set up to receive electronic remits (835s) and electronic payments. Daybook submits the enrollment, tracks it with the payer, and handles the action-required paperwork payers send back, so downstream workflows such as remittance and posting have something to work on.

### At a glance

- **Workflow:** ERA and EFT enrollment
- **Stage:** Onboarding, before remits and payments flow
- **Primary users:** Provider onboarding and credentialing teams
- **Core question:** Will this payer send us 835s and pay us electronically?
- **In scope:** Submit enrollment · Track status · Action required · Approval
- **Downstream workflows:** Remittance and posting · Denials and appeals
- **Consumption options:** API · Webhooks · MCP

### What this workflow enables

- Submit ERA, EFT or both for a provider with a payer in one request.
- Track every enrollment to approval without checking each portal.
- Get told the moment a payer wants a signature, a document or a bank letter.
- Know when 835s will start, so remittance can pick them up.

### Typical flow

1. **Submit.** `POST /v1/enrollments` with the provider, the payer, the transactions and, for EFT, the bank account. You receive `enrollment.submitted`.
2. **Daybook works the enrollment.** It submits through the payer's enrollment channel, portal included, and checks status on a schedule.
3. **Action required.** When the payer wants something, you receive `enrollment.action_required` with what it asked for and by when.
4. **Approval.** `enrollment.approved` when the payer confirms. Remits start flowing into the remittance workflow.

### Journeys

- **Onboard a new provider:** Enroll a new NPI with every payer it bills.
- **Clear the paperwork:** Answer signature and document requests as they come.
- **Switch a bank account:** Re-enroll EFT when the practice changes banks.
- **Audit coverage:** See which providers are set up with which payers.

### Use cases

- [ERA and EFT enrollment at provider onboarding](https://daybookhealthcare.com/docs/use-cases/enrollment-onboarding.md): A provider added to your product is enrolled with each payer for 835s and electronic payment, tracked to approval.

### APIs powering this workflow

- `POST /v1/enrollments`: [Submit an enrollment](https://daybookhealthcare.com/docs/api-reference/enrollments/create.md)
- `GET /v1/enrollments/{id}`: [Retrieve an enrollment](https://daybookhealthcare.com/docs/api-reference/enrollments/get.md)

### Events you receive

- `enrollment.submitted`: Daybook submitted the enrollment to the payer.
- `enrollment.action_required`: The payer wants something: a signature, a document, a letter.
- `enrollment.approved`: The payer confirmed. ERA or EFT is live.
- `enrollment.rejected`: The payer rejected it, with the reason.

Example event:

```json
{
  "id": "evt_01JBXP3A4C6E8G0J2M4P6R8T0W",
  "type": "enrollment.action_required",
  "created_at": "2026-10-29T13:00:00Z",
  "mode": "live",
  "data": {
    "id": "enr_01JBXC7F2D9R",
    "payer": "meridian",
    "transactions": [
      "era",
      "eft"
    ],
    "action_required": {
      "type": "verification_letter",
      "description": "Upload a bank letter confirming the account for EFT.",
      "due_by": "2026-11-12"
    }
  }
}
```

---

## Eligibility and benefits

Check insurance eligibility and benefits over 270/271 with the Daybook API, in real time or by the thousand, and hear when a patient's coverage changes.

Source: https://daybookhealthcare.com/docs/workflows/eligibility

> "Is this patient covered, and what will they owe?"

The **Eligibility and benefits** workflow answers coverage questions before care. Daybook sends the 270, reads the 271 and returns plain fields: whether coverage is active, the plan, and what is left of the deductible and out-of-pocket maximum. Run one check at a time or a whole schedule at once.

### At a glance

- **Workflow:** Eligibility and benefits
- **Stage:** Before the visit, and again before billing
- **Primary users:** Front desk, scheduling and billing teams
- **Core question:** Is this patient covered, and what will they owe?
- **Transactions:** X12 270 / 271
- **Volume:** Real time, or batches up to 1,000
- **Consumption options:** API · Webhooks · MCP

### What this workflow enables

- Verify coverage on the date of service in real time.
- Read deductible, out-of-pocket, copay and coinsurance as numbers.
- Check tomorrow's whole schedule in one batch.
- Get told when a patient's coverage changes between visits.

### Typical flow

1. **Send the check.** `POST /v1/eligibility/checks` with the payer, provider and patient.
2. **Daybook runs the 270/271.** Through the clearinghouse, and reads the 271 into fields.
3. **Answer.** Real-time checks answer in the response. Batches send `eligibility.completed` per patient.
4. **Watch for changes.** Re-checks that find different coverage send `coverage.changed`.

### Journeys

- **Verify before the visit:** Check every patient on tomorrow's schedule.
- **Estimate what the patient owes:** Use the remaining deductible and coinsurance.
- **Catch terminated coverage:** Find out before the claim is denied.
- **Escalate to a call:** When the 271 is unclear, start a payer call.

### Use cases

- [Verify coverage before every visit](https://daybookhealthcare.com/docs/use-cases/eligibility-before-visit.md): Tomorrow's schedule checked over 270/271 tonight, with inactive coverage flagged before the patient arrives.
- [Catch terminated coverage on open claims](https://daybookhealthcare.com/docs/use-cases/coverage-watch.md): When a patient's coverage changes, your product flags their open claims and visits, and can call the payer to confirm.

### APIs powering this workflow

- `POST /v1/eligibility/checks`: [Check eligibility](https://daybookhealthcare.com/docs/api-reference/eligibility/create-check.md)

### Events you receive

- `eligibility.completed`: A batched check finished.
- `coverage.changed`: A re-check found different coverage than the last one.

Example event:

```json
{
  "id": "evt_01JBXQ1A4C6E8G0J2M4P6R8T0W",
  "type": "coverage.changed",
  "created_at": "2026-10-29T06:00:00Z",
  "mode": "live",
  "data": {
    "id": "elig_01JBXQ0",
    "previous": {
      "active": true,
      "plan_name": "Bayline Choice PPO"
    },
    "current": {
      "active": false,
      "coverage_end": "2026-10-15"
    }
  }
}
```

---

## Claim status

Run 276/277 claim status checks with the Daybook API in real time and at volume, started by your own rules, and hear back only when a status moves.

Source: https://daybookhealthcare.com/docs/workflows/claim-status

> "Where is this claim, and has anything changed?"

The **Claim status** workflow keeps track of every claim you have sent. Daybook runs 276/277 status checks in real time and at volume, started by you or by your own rules, such as no response in 30 days. You hear about a claim only when its status changes.

### At a glance

- **Workflow:** Claim status
- **Stage:** After submission, until payment or denial
- **Primary users:** AR follow-up teams
- **Core question:** Where is this claim, and has anything changed?
- **Transactions:** X12 276 / 277
- **Triggers:** On demand · Batches · Your rules
- **Consumption options:** API · Webhooks · MCP

### What this workflow enables

- Check any claim's status in real time.
- Check thousands in one batch.
- Let rules start checks, such as every claim with no response after 30 days.
- Hear about a claim only when its status changes.
- Hand off to a payer call when the 277 is not enough.

### Typical flow

1. **Start a check, or let a rule.** `POST /v1/claim-status/checks`, a batch, or a [rule](https://daybookhealthcare.com/docs/worklists-and-rules).
2. **Daybook runs the 276/277.** And reads the 277 into a normalized status: paid, denied, pending, in process, returned or not on file.
3. **You hear about changes.** `claim.status_changed` when the status differs from the last check.
4. **Next step.** Denied claims flow into denials and appeals. Silent ones can escalate to a payer call.

### Journeys

- **Chase silent claims:** Check every claim with no response after 30 days.
- **Confirm a payment:** See the paid amount and EFT number before the 835.
- **Catch denials early:** React the day the status changes, not when the remit arrives.
- **Escalate to a call:** Start a payer call when the 277 says pending for too long.

### Use cases

- [Nightly claim status sweep into your PM system](https://daybookhealthcare.com/docs/use-cases/claim-status-sweep.md): Every unpaid claim checked over 276/277 overnight, and only the claims that moved come back to you.
- [A Claude agent that works your AR list](https://daybookhealthcare.com/docs/use-cases/mcp-ar-agent.md): Claude checks each claim, reads the payer's last answer and the denial, and drafts the appeal for a person to approve.
- [Recheck silent claims by phone until they move](https://daybookhealthcare.com/docs/use-cases/silent-claim-recheck.md): Claims with no 276/277 answer get a payer call that repeats every few days and stops once the claim is paid.

### APIs powering this workflow

- `POST /v1/claim-status/checks`: [Check claim status](https://daybookhealthcare.com/docs/api-reference/claim-status/create-check.md)
- `POST /v1/rules`: [Create a rule](https://daybookhealthcare.com/docs/api-reference/rules/create.md)

### Events you receive

- `claim_status.completed`: A batched check finished.
- `claim.status_changed`: A claim's status differs from the last check.

Example event:

```json
{
  "id": "evt_01JBXR4A4C6E8G0J2M4P6R8T0W",
  "type": "claim.status_changed",
  "created_at": "2026-10-29T15:30:02Z",
  "mode": "live",
  "data": {
    "claim": "A-20817-1",
    "payer": "keystone",
    "previous": "in_process",
    "current": "paid",
    "check": "cs_01JBXE4H9M2T",
    "paid_amount_cents": 31200
  }
}
```

---

## Remittance and posting

Pull 835 remits with the Daybook API, match them to their claims and deposits, and approve the proposed posting entries before your write-back runs.

Source: https://daybookhealthcare.com/docs/workflows/remittance

> "What did the payer pay, did the money arrive, and how do we post it?"

The **Remittance and posting** workflow turns 835s into postings. Daybook pulls each remit, matches it to your claims and to the bank deposit, and proposes the posting entries for each payment. Unmatched payments are flagged, and every denied line flows into denials and appeals.

### At a glance

- **Workflow:** Remittance and posting
- **Stage:** After payment
- **Primary users:** Payment posters, reconciliation and finance
- **Core question:** What did the payer pay, did the money arrive, and how do we post it?
- **Transactions:** X12 835, bank deposits
- **In scope:** Retrieve · Match · Propose posting · Flag unmatched
- **Consumption options:** API · Webhooks · MCP

### What this workflow enables

- Receive every 835 as structured data, adjustments and remark codes included.
- Match each payment to its claims and to the deposit that carried it.
- Get proposed posting entries ready for your PM system.
- See payments with no matching deposit, and deposits with no 835.

### Typical flow

1. **Remit arrives.** From the clearinghouse or a portal. You receive `remit.received`.
2. **Match.** Daybook matches it to claims and to the deposit. You receive `remit.matched`, or `payment.unmatched`.
3. **Posting proposed.** `posting.proposed` with payment, adjustment and patient-responsibility entries.
4. **Approve and write back.** Approve with `POST /v1/remits/{id}/posting/approve`. `posting.approved` is where your write-back picks it up.

### Journeys

- **Post a payment:** From 835 to posted entries without keying.
- **Reconcile the bank:** Match deposits to remits and find what is missing.
- **Find missing remits:** Money arrived with no 835. Pull it from the portal.
- **Route denials:** Denied lines go straight to denials and appeals.

### Use cases

- [835 to posting in your PM system](https://daybookhealthcare.com/docs/use-cases/remit-to-posting.md): Every 835 matched to its claims and deposit, and posted to the PM system once a person approves it.
- [Find a missing remit in the payer portal](https://daybookhealthcare.com/docs/use-cases/portal-remit-lookup.md): When a payment shows up with no 835, Daybook signs in to the portal and brings the remit back.
- [Recheck silent claims by phone until they move](https://daybookhealthcare.com/docs/use-cases/silent-claim-recheck.md): Claims with no 276/277 answer get a payer call that repeats every few days and stops once the claim is paid.
- [Reconcile deposits to remits](https://daybookhealthcare.com/docs/use-cases/deposit-reconciliation.md): Every deposit tied to its 835, and finance hears about each one that is not.

### APIs powering this workflow

- `GET /v1/remits`: [List remits](https://daybookhealthcare.com/docs/api-reference/remits/list.md)
- `GET /v1/remits/{id}`: [Retrieve a remit](https://daybookhealthcare.com/docs/api-reference/remits/get.md)
- `POST /v1/remits/{id}/posting/approve`: [Approve a posting](https://daybookhealthcare.com/docs/api-reference/remits/approve-posting.md)

### Events you receive

- `remit.received`: A new 835 arrived.
- `remit.matched`: The remit matched its claims and deposit.
- `payment.unmatched`: A payment or deposit has no match.
- `posting.proposed`: Posting entries are ready to review.
- `posting.approved`: Posting entries were approved and are ready to write back.

Example event:

```json
{
  "id": "evt_01JBXS9A4C6E8G0J2M4P6R8T0W",
  "type": "posting.proposed",
  "created_at": "2026-10-22T09:15:00Z",
  "mode": "live",
  "data": {
    "remit": "remit_01JBXF8B3C4V",
    "payer": "keystone",
    "payment_amount_cents": 31200,
    "entries": [
      {
        "type": "payment",
        "claim": "A-20817-1",
        "amount_cents": 31200
      },
      {
        "type": "adjustment",
        "claim": "A-20817-1",
        "code": "CO-45",
        "amount_cents": 6800
      },
      {
        "type": "transfer_to_patient",
        "claim": "A-20817-1",
        "amount_cents": 3000
      }
    ]
  }
}
```

---

## Denials and appeals

Read CARC and RARC codes with the Daybook API, sort every denial by cause with its next step and deadline, and draft the appeal letter in one call.

Source: https://daybookhealthcare.com/docs/workflows/denials-and-appeals

> "Why was this denied, and what do we do about it?"

The **Denials and appeals** workflow reads each denial's codes and sorts it by cause, so "denied because of X" can trigger "do Y". When an appeal is the right move, Daybook drafts the letter from the denial data for a biller to review and send. When it isn't, it says why.

### At a glance

- **Workflow:** Denials and appeals
- **Stage:** After a denial on a 277 or 835
- **Primary users:** Denial management and appeals teams
- **Core question:** Why was this denied, and what do we do about it?
- **Inputs:** CARC · RARC · Claim and remit data
- **Outputs:** Cause · Recommended action · Appeal letter
- **Consumption options:** API · Webhooks · MCP

### What this workflow enables

- Sort every denial by cause: authorization, eligibility, coding, timely filing, duplicate and more.
- Get a recommended next step for each one.
- Trigger your own rules from the cause, such as a portal attachment for missing records.
- Draft the appeal letter for a biller to review and send.

### Typical flow

1. **Denial arrives.** On a remit or a status change. Daybook reads the CARC and RARC codes.
2. **Classified.** `denial.classified` with the cause, the recommended action and the appeal deadline.
3. **Your rules act.** Route by cause: appeal, correct and resubmit, call the payer, bill the patient or secondary.
4. **Appeal drafted.** `POST /v1/appeals`. `appeal.drafted` when the letter is ready for review.

### Journeys

- **Work denials by cause:** Group the queue by why, not by payer.
- **Appeal missing auth:** Draft the appeal with the auth on file.
- **Resubmit coding errors:** Send the fix back to your billing system.
- **Watch the deadline:** Every denial carries its appeal deadline.

### Use cases

- [Call the payer from your denial queue](https://daybookhealthcare.com/docs/use-cases/denial-call-queue.md): Every denial a phone call settles gets one, and the rep's answer lands back on the same ticket.
- [Appeal letters drafted from denial data](https://daybookhealthcare.com/docs/use-cases/appeal-drafts.md): A drafted appeal waiting for every denial worth fighting, inside its deadline.
- [A Claude agent that works your AR list](https://daybookhealthcare.com/docs/use-cases/mcp-ar-agent.md): Claude checks each claim, reads the payer's last answer and the denial, and drafts the appeal for a person to approve.

### APIs powering this workflow

- `GET /v1/denials/{id}`: [Retrieve a denial](https://daybookhealthcare.com/docs/api-reference/denials/get.md)
- `POST /v1/appeals`: [Draft an appeal](https://daybookhealthcare.com/docs/api-reference/appeals/create.md)

### Events you receive

- `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.

Example event:

```json
{
  "id": "evt_01JBXT6A4C6E8G0J2M4P6R8T0W",
  "type": "denial.classified",
  "created_at": "2026-10-22T09:15:04Z",
  "mode": "live",
  "data": {
    "id": "den_01JBXG2N5R8W",
    "claim": "A-31120-1",
    "codes": {
      "group": "CO",
      "carc": "197",
      "rarc": [
        "N54"
      ]
    },
    "cause": "missing_auth",
    "recommended_action": "appeal",
    "appeal_deadline": "2027-04-19",
    "amount_cents": 88000
  }
}
```

---

## What teams build on Daybook

What teams build on the Daybook API, from denial call queues to 835 posting, each with its endpoints, its steps and a prompt for Claude, ChatGPT or Cursor.

Source: https://daybookhealthcare.com/docs/use-cases

- [Call the payer from your denial queue](https://daybookhealthcare.com/docs/use-cases/denial-call-queue.md) (Billing companies): Every denial a phone call settles gets one, and the rep's answer lands back on the same ticket.
- [Nightly claim status sweep into your PM system](https://daybookhealthcare.com/docs/use-cases/claim-status-sweep.md) (Billing companies): Every unpaid claim checked over 276/277 overnight, and only the claims that moved come back to you.
- [Verify coverage before every visit](https://daybookhealthcare.com/docs/use-cases/eligibility-before-visit.md) (Practices): Tomorrow's schedule checked over 270/271 tonight, with inactive coverage flagged before the patient arrives.
- [835 to posting in your PM system](https://daybookhealthcare.com/docs/use-cases/remit-to-posting.md) (RCM and EHR vendors): Every 835 matched to its claims and deposit, and posted to the PM system once a person approves it.
- [Appeal letters drafted from denial data](https://daybookhealthcare.com/docs/use-cases/appeal-drafts.md) (Billing companies): A drafted appeal waiting for every denial worth fighting, inside its deadline.
- [Find a missing remit in the payer portal](https://daybookhealthcare.com/docs/use-cases/portal-remit-lookup.md) (Billing companies): When a payment shows up with no 835, Daybook signs in to the portal and brings the remit back.
- [ERA and EFT enrollment at provider onboarding](https://daybookhealthcare.com/docs/use-cases/enrollment-onboarding.md) (RCM and EHR vendors): A provider added to your product is enrolled with each payer for 835s and electronic payment, tracked to approval.
- [Post finished payer calls to Slack](https://daybookhealthcare.com/docs/use-cases/slack-call-alerts.md) (Billing companies): 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.
- [A Claude agent that works your AR list](https://daybookhealthcare.com/docs/use-cases/mcp-ar-agent.md) (Billing companies): Claude checks each claim, reads the payer's last answer and the denial, and drafts the appeal for a person to approve.
- [Recheck silent claims by phone until they move](https://daybookhealthcare.com/docs/use-cases/silent-claim-recheck.md) (Billing companies): Claims with no 276/277 answer get a payer call that repeats every few days and stops once the claim is paid.
- [Reconcile deposits to remits](https://daybookhealthcare.com/docs/use-cases/deposit-reconciliation.md) (Practices): Every deposit tied to its 835, and finance hears about each one that is not.
- [Catch terminated coverage on open claims](https://daybookhealthcare.com/docs/use-cases/coverage-watch.md) (RCM and EHR vendors): When a patient's coverage changes, your product flags their open claims and visits, and can call the payer to confirm.

---

## 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. Built on the Daybook API, with the steps, endpoints, events and a prompt for your AI assistant.

Source: https://daybookhealthcare.com/docs/use-cases/denial-call-queue

[All use cases](https://daybookhealthcare.com/docs/use-cases.md)

- **For:** Billing companies
- **Outcome:** Every denial a phone call settles gets one, and the rep's answer lands back on the same ticket.
- **Workflows:** [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls.md), [Denials and appeals](https://daybookhealthcare.com/docs/workflows/denials-and-appeals.md)
- **Replaces:** The status call a biller places by hand, hold included.

### 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.

### Built on

- [`GET /v1/denials/{id}`](https://daybookhealthcare.com/docs/api-reference/denials/get.md): Retrieve a denial
- [`POST /v1/calls`](https://daybookhealthcare.com/docs/api-reference/calls/create.md): Start a call
- [`GET /v1/calls/{id}`](https://daybookhealthcare.com/docs/api-reference/calls/get.md): Retrieve a call

Events: `denial.classified`, `call.completed`, `call.failed`

### The prompt

```text
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.
```

---

## Nightly claim status sweep into your PM system

Every unpaid claim checked over 276/277 overnight, and only the claims that moved come back to you. Built on the Daybook API, with the steps, endpoints, events and a prompt for your AI assistant.

Source: https://daybookhealthcare.com/docs/use-cases/claim-status-sweep

[All use cases](https://daybookhealthcare.com/docs/use-cases.md)

- **For:** Billing companies
- **Outcome:** Every unpaid claim checked over 276/277 overnight, and only the claims that moved come back to you.
- **Workflows:** [Claim status](https://daybookhealthcare.com/docs/workflows/claim-status.md)
- **Replaces:** A biller working the aging report claim by claim.

### How it works

1. Each night, export open AR from your PM system and send it to Daybook as a worklist.
2. A rule checks every claim with no answer after 30 days.
3. Daybook runs the 276/277 checks and sends claim.status_changed only when a status moves.
4. Your handler writes the new status onto the claim in your PM system, and denied claims go to your denial queue.

### Built on

- [`POST /v1/worklists`](https://daybookhealthcare.com/docs/api-reference/worklists/create.md): Create a worklist
- [`POST /v1/rules`](https://daybookhealthcare.com/docs/api-reference/rules/create.md): Create a rule
- [`POST /v1/claim-status/checks`](https://daybookhealthcare.com/docs/api-reference/claim-status/create-check.md): Check claim status

Events: `claim.status_changed`, `claim_status.completed`

### The prompt

```text
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: Nightly claim status sweep into your PM system
For: Billing companies
Outcome: Every unpaid claim checked over 276/277 overnight, and only the claims that moved come back to you.

What to build:
A nightly job that exports open AR from my PM system to a CSV at a signed URL, creates a worklist with POST /v1/worklists that applies a rule made once with POST /v1/rules (no response after 30 days runs claim_status.check), and a webhook handler that takes claim.status_changed and writes the normalized status (paid, denied, pending, in process, returned or not on file) onto the matching claim. Denied claims also go to our denial queue. claim_status.completed, sent as each batched check finishes, goes in a log so the night's progress can be counted.

How it works:
1. Each night, export open AR from your PM system and send it to Daybook as a worklist.
2. A rule checks every claim with no answer after 30 days.
3. Daybook runs the 276/277 checks and sends claim.status_changed only when a status moves.
4. Your handler writes the new status onto the claim in your PM system, and denied claims go to your denial queue.

Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/claim-status.md
- https://daybookhealthcare.com/docs/api-reference/worklists/create.md
- https://daybookhealthcare.com/docs/api-reference/rules/create.md
- https://daybookhealthcare.com/docs/api-reference/claim-status/create-check.md
- https://daybookhealthcare.com/docs/worklists-and-rules.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 /worklists: Create a worklist
- POST /rules: Create a rule
- POST /claim-status/checks: Check claim status

Webhook events: claim.status_changed, claim_status.completed

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 PM system we run and how it exports open AR, then sketch the CSV columns and the job schedule before writing code.
```

---

## Verify coverage before every visit

Tomorrow's schedule checked over 270/271 tonight, with inactive coverage flagged before the patient arrives. Built on the Daybook API, with the steps, endpoints, events and a prompt for your AI assistant.

Source: https://daybookhealthcare.com/docs/use-cases/eligibility-before-visit

[All use cases](https://daybookhealthcare.com/docs/use-cases.md)

- **For:** Practices
- **Outcome:** Tomorrow's schedule checked over 270/271 tonight, with inactive coverage flagged before the patient arrives.
- **Workflows:** [Eligibility and benefits](https://daybookhealthcare.com/docs/workflows/eligibility.md)
- **Replaces:** Front desk staff checking each patient on a portal the morning of the visit.

### How it works

1. Pull tomorrow's appointments from your scheduling system.
2. Send one check per patient with POST /v1/eligibility/checks, or up to 1,000 at once with POST /v1/eligibility/checks/batch.
3. Real-time checks answer in the response; batches send eligibility.completed per patient.
4. Flag the appointment for the front desk when coverage is not active.

### Built on

- [`POST /v1/eligibility/checks`](https://daybookhealthcare.com/docs/api-reference/eligibility/create-check.md): Check eligibility

Events: `eligibility.completed`, `coverage.changed`

### The prompt

```text
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: Verify coverage before every visit
For: Practices
Outcome: Tomorrow's schedule checked over 270/271 tonight, with inactive coverage flagged before the patient arrives.

What to build:
An evening job that reads tomorrow's appointments, sends a 270/271 eligibility check per patient as one batch with POST /v1/eligibility/checks/batch (up to 1,000 checks in a checks array; service type codes from the appointment type, provider NPI from the schedule), stores the answer next to the appointment, and flags every appointment whose coverage is not active on the front desk's list. A webhook handler takes eligibility.completed for batched checks and coverage.changed when a later re-check finds different coverage.

How it works:
1. Pull tomorrow's appointments from your scheduling system.
2. Send one check per patient with POST /v1/eligibility/checks, or up to 1,000 at once with POST /v1/eligibility/checks/batch.
3. Real-time checks answer in the response; batches send eligibility.completed per patient.
4. Flag the appointment for the front desk when coverage is not active.

Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/eligibility.md
- https://daybookhealthcare.com/docs/api-reference/eligibility/create-check.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 /eligibility/checks: Check eligibility

Webhook events: eligibility.completed, coverage.changed

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 scheduling system we use and which appointment types map to which service type codes, then show the data model before writing code.
```

---

## 835 to posting in your PM system

Every 835 matched to its claims and deposit, and posted to the PM system once a person approves it. Built on the Daybook API, with the steps, endpoints, events and a prompt for your AI assistant.

Source: https://daybookhealthcare.com/docs/use-cases/remit-to-posting

[All use cases](https://daybookhealthcare.com/docs/use-cases.md)

- **For:** RCM and EHR vendors
- **Outcome:** Every 835 matched to its claims and deposit, and posted to the PM system once a person approves it.
- **Workflows:** [Remittance and posting](https://daybookhealthcare.com/docs/workflows/remittance.md)
- **Replaces:** Keying 835 lines into the PM system by hand.

### How it works

1. remit.received tells you a new 835 is in.
2. remit.matched lands when it ties to claims and a deposit, and posting.proposed carries the entries.
3. A poster reviews the entries and approves with POST /v1/remits/{id}/posting/approve.
4. posting.approved fires and your write-back posts the lines to the PM system.

### Built on

- [`GET /v1/remits`](https://daybookhealthcare.com/docs/api-reference/remits/list.md): List remits
- [`GET /v1/remits/{id}`](https://daybookhealthcare.com/docs/api-reference/remits/get.md): Retrieve a remit
- [`POST /v1/remits/{id}/posting/approve`](https://daybookhealthcare.com/docs/api-reference/remits/approve-posting.md): Approve a posting

Events: `remit.received`, `remit.matched`, `posting.proposed`, `posting.approved`

### The prompt

```text
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: 835 to posting in your PM system
For: RCM and EHR vendors
Outcome: Every 835 matched to its claims and deposit, and posted to the PM system once a person approves it.

What to build:
A posting screen and write-back for our product: a webhook handler that records remit.received and remit.matched, shows each posting.proposed with its payment, adjustment and patient-responsibility entries for a poster to review, sends the poster's decision with POST /v1/remits/{id}/posting/approve, and on posting.approved writes the entries to the PM system's ledger, once per remit even if the event arrives twice. A daily GET /v1/remits pass catches anything a missed webhook left behind.

How it works:
1. remit.received tells you a new 835 is in.
2. remit.matched lands when it ties to claims and a deposit, and posting.proposed carries the entries.
3. A poster reviews the entries and approves with POST /v1/remits/{id}/posting/approve.
4. posting.approved fires and your write-back posts the lines to the PM system.

Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/remittance.md
- https://daybookhealthcare.com/docs/api-reference/remits/list.md
- https://daybookhealthcare.com/docs/api-reference/remits/get.md
- https://daybookhealthcare.com/docs/api-reference/remits/approve-posting.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 /remits: List remits
- GET /remits/{id}: Retrieve a remit
- POST /remits/{id}/posting/approve: Approve a posting

Webhook events: remit.received, remit.matched, posting.proposed, posting.approved

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 PM system the write-back targets and how it accepts payment lines, then propose the review screen and the write-back module before writing code.
```

---

## Appeal letters drafted from denial data

A drafted appeal waiting for every denial worth fighting, inside its deadline. Built on the Daybook API, with the steps, endpoints, events and a prompt for your AI assistant.

Source: https://daybookhealthcare.com/docs/use-cases/appeal-drafts

[All use cases](https://daybookhealthcare.com/docs/use-cases.md)

- **For:** Billing companies
- **Outcome:** A drafted appeal waiting for every denial worth fighting, inside its deadline.
- **Workflows:** [Denials and appeals](https://daybookhealthcare.com/docs/workflows/denials-and-appeals.md)

### 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.

### Built on

- [`GET /v1/denials/{id}`](https://daybookhealthcare.com/docs/api-reference/denials/get.md): Retrieve a denial
- [`POST /v1/appeals`](https://daybookhealthcare.com/docs/api-reference/appeals/create.md): Draft an appeal

Events: `denial.classified`, `appeal.drafted`

### The prompt

```text
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.
```

---

## 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. Built on the Daybook API, with the steps, endpoints, events and a prompt for your AI assistant.

Source: https://daybookhealthcare.com/docs/use-cases/portal-remit-lookup

[All use cases](https://daybookhealthcare.com/docs/use-cases.md)

- **For:** Billing companies
- **Outcome:** When a payment shows up with no 835, Daybook signs in to the portal and brings the remit back.
- **Workflows:** [Payer portals](https://daybookhealthcare.com/docs/workflows/payer-portals.md), [Remittance and posting](https://daybookhealthcare.com/docs/workflows/remittance.md)
- **Replaces:** A poster signing in to a payer portal to hunt for one remit.

### 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.

### Built on

- [`POST /v1/portal-tasks`](https://daybookhealthcare.com/docs/api-reference/portal-tasks/create.md): Start a portal task
- [`GET /v1/portal-tasks/{id}`](https://daybookhealthcare.com/docs/api-reference/portal-tasks/get.md): Retrieve a portal task
- [`GET /v1/remits`](https://daybookhealthcare.com/docs/api-reference/remits/list.md): List remits

Events: `payment.unmatched`, `portal_task.completed`, `portal_task.failed`

### The prompt

```text
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.
```

---

## ERA and EFT enrollment at provider onboarding

A provider added to your product is enrolled with each payer for 835s and electronic payment, tracked to approval. Built on the Daybook API, with the steps, endpoints, events and a prompt for your AI assistant.

Source: https://daybookhealthcare.com/docs/use-cases/enrollment-onboarding

[All use cases](https://daybookhealthcare.com/docs/use-cases.md)

- **For:** RCM and EHR vendors
- **Outcome:** A provider added to your product is enrolled with each payer for 835s and electronic payment, tracked to approval.
- **Workflows:** [ERA and EFT enrollment](https://daybookhealthcare.com/docs/workflows/enrollment.md)
- **Replaces:** A spreadsheet of enrollments chased payer by payer.

### How it works

1. When a provider is added, submit one enrollment per payer with POST /v1/enrollments.
2. enrollment.submitted confirms it went in.
3. enrollment.action_required says what the payer wants, such as a signature, and by when.
4. enrollment.approved or enrollment.rejected closes it; your onboarding screen shows each payer's state.

### Built on

- [`POST /v1/enrollments`](https://daybookhealthcare.com/docs/api-reference/enrollments/create.md): Submit an enrollment
- [`GET /v1/enrollments/{id}`](https://daybookhealthcare.com/docs/api-reference/enrollments/get.md): Retrieve an enrollment

Events: `enrollment.submitted`, `enrollment.action_required`, `enrollment.approved`, `enrollment.rejected`

### The prompt

```text
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: ERA and EFT enrollment at provider onboarding
For: RCM and EHR vendors
Outcome: A provider added to your product is enrolled with each payer for 835s and electronic payment, tracked to approval.

What to build:
An onboarding step in our product: when a provider is added with their payers, submit an ERA and EFT enrollment per payer with POST /v1/enrollments (provider NPI, tax id and name, bank account for EFT, a contact), and a per-payer status board fed by enrollment.submitted, enrollment.action_required (with what the payer asked for and the date), enrollment.approved and enrollment.rejected. Action items go to the provider's admin.

How it works:
1. When a provider is added, submit one enrollment per payer with POST /v1/enrollments.
2. enrollment.submitted confirms it went in.
3. enrollment.action_required says what the payer wants, such as a signature, and by when.
4. enrollment.approved or enrollment.rejected closes it; your onboarding screen shows each payer's state.

Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/enrollment.md
- https://daybookhealthcare.com/docs/api-reference/enrollments/create.md
- https://daybookhealthcare.com/docs/api-reference/enrollments/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):
- POST /enrollments: Submit an enrollment
- GET /enrollments/{id}: Retrieve an enrollment

Webhook events: enrollment.submitted, enrollment.action_required, enrollment.approved, enrollment.rejected

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 providers and their payers live in our product, then sketch the status board and its states before writing code.
```

---

## 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. Built on the Daybook API, with the steps, endpoints, events and a prompt for your AI assistant.

Source: https://daybookhealthcare.com/docs/use-cases/slack-call-alerts

[All use cases](https://daybookhealthcare.com/docs/use-cases.md)

- **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.
- **Workflows:** [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls.md)

### 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

- [`POST /v1/webhook-endpoints`](https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/create.md): Create a webhook endpoint
- [`POST /v1/webhook-endpoints/{id}/test`](https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/test.md): Send a test event
- [`GET /v1/calls/{id}`](https://daybookhealthcare.com/docs/api-reference/calls/get.md): Retrieve a call

Events: `call.completed`, `call.handoff_ready`, `call.failed`

### The prompt

```text
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.
```

---

## A Claude agent that works your AR list

Claude checks each claim, reads the payer's last answer and the denial, and drafts the appeal for a person to approve. Built on the Daybook API, with the steps, endpoints, events and a prompt for your AI assistant.

Source: https://daybookhealthcare.com/docs/use-cases/mcp-ar-agent

[All use cases](https://daybookhealthcare.com/docs/use-cases.md)

- **For:** Billing companies
- **Outcome:** Claude checks each claim, reads the payer's last answer and the denial, and drafts the appeal for a person to approve.
- **Workflows:** [Claim status](https://daybookhealthcare.com/docs/workflows/claim-status.md), [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls.md), [Denials and appeals](https://daybookhealthcare.com/docs/workflows/denials-and-appeals.md)

### How it works

1. Add Daybook's MCP server to Claude, Claude Code or Cursor.
2. Hand the agent your AR list.
3. It runs check_claim_status, reads the last payer call with get_call and the denial with get_denial.
4. It drafts appeals with draft_appeal and leaves every approval to your team.

### Built on

- [`POST /v1/claim-status/checks`](https://daybookhealthcare.com/docs/api-reference/claim-status/create-check.md): Check claim status
- [`GET /v1/calls/{id}`](https://daybookhealthcare.com/docs/api-reference/calls/get.md): Retrieve a call
- [`GET /v1/denials/{id}`](https://daybookhealthcare.com/docs/api-reference/denials/get.md): Retrieve a denial
- [`POST /v1/appeals`](https://daybookhealthcare.com/docs/api-reference/appeals/create.md): Draft an appeal

### The prompt

```text
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: A Claude agent that works your AR list
For: Billing companies
Outcome: Claude checks each claim, reads the payer's last answer and the denial, and drafts the appeal for a person to approve.

What to build:
An agent setup over Daybook's MCP server (https://mcp.daybookhealthcare.com/mcp) that works an AR list I paste or attach: for each claim it runs check_claim_status, reads the last payer call with get_call when the claim is pending, reads the denial with get_denial when it is denied, drafts an appeal with draft_appeal when the cause is one we appeal, and ends with a table per claim: status, what the payer said, the next step and the appeal drafted, if any.

How it works:
1. Add Daybook's MCP server to Claude, Claude Code or Cursor.
2. Hand the agent your AR list.
3. It runs check_claim_status, reads the last payer call with get_call and the denial with get_denial.
4. It drafts appeals with draft_appeal and leaves every approval to your team.

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/denials-and-appeals.md
- https://daybookhealthcare.com/docs/api-reference/claim-status/create-check.md
- https://daybookhealthcare.com/docs/api-reference/calls/get.md
- https://daybookhealthcare.com/docs/api-reference/denials/get.md
- https://daybookhealthcare.com/docs/api-reference/appeals/create.md
- https://daybookhealthcare.com/docs/mcp.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 /claim-status/checks: Check claim status
- GET /calls/{id}: Retrieve a call
- GET /denials/{id}: Retrieve a denial
- POST /appeals: Draft an appeal

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.

Write the MCP setup for Claude Code and the agent's instructions, then run it on three made-up claims from the sample payers.
```

---

## 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. Built on the Daybook API, with the steps, endpoints, events and a prompt for your AI assistant.

Source: https://daybookhealthcare.com/docs/use-cases/silent-claim-recheck

[All use cases](https://daybookhealthcare.com/docs/use-cases.md)

- **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.
- **Workflows:** [Claim status](https://daybookhealthcare.com/docs/workflows/claim-status.md), [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls.md), [Remittance and posting](https://daybookhealthcare.com/docs/workflows/remittance.md)
- **Replaces:** A follow-up reminder a biller sets, and the call they make each time it fires.

### 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.

### Built on

- [`POST /v1/rules`](https://daybookhealthcare.com/docs/api-reference/rules/create.md): Create a rule
- [`POST /v1/calls`](https://daybookhealthcare.com/docs/api-reference/calls/create.md): Start a call
- [`POST /v1/calls/{id}/cancel`](https://daybookhealthcare.com/docs/api-reference/calls/cancel.md): Cancel a call

Events: `claim.status_changed`, `call.completed`, `remit.received`

### The prompt

```text
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.
```

---

## Reconcile deposits to remits

Every deposit tied to its 835, and finance hears about each one that is not. Built on the Daybook API, with the steps, endpoints, events and a prompt for your AI assistant.

Source: https://daybookhealthcare.com/docs/use-cases/deposit-reconciliation

[All use cases](https://daybookhealthcare.com/docs/use-cases.md)

- **For:** Practices
- **Outcome:** Every deposit tied to its 835, and finance hears about each one that is not.
- **Workflows:** [Remittance and posting](https://daybookhealthcare.com/docs/workflows/remittance.md)
- **Replaces:** Matching bank lines to remits in a spreadsheet at month end.

### How it works

1. remit.matched ties an 835 to its claims and its deposit.
2. payment.unmatched flags a deposit or remit with no match.
3. Open a finance task with the payer and the amount in cents.
4. Review open items daily against GET /v1/remits.

### Built on

- [`GET /v1/remits`](https://daybookhealthcare.com/docs/api-reference/remits/list.md): List remits
- [`GET /v1/remits/{id}`](https://daybookhealthcare.com/docs/api-reference/remits/get.md): Retrieve a remit

Events: `remit.matched`, `payment.unmatched`

### The prompt

```text
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: Reconcile deposits to remits
For: Practices
Outcome: Every deposit tied to its 835, and finance hears about each one that is not.

What to build:
A reconciliation view for our finance team: a webhook handler records remit.matched against the deposit, opens a task for every payment.unmatched with the payer and amount in integer cents, and a daily job lists remits with GET /v1/remits to show what is matched, what is open and for how long.

How it works:
1. remit.matched ties an 835 to its claims and its deposit.
2. payment.unmatched flags a deposit or remit with no match.
3. Open a finance task with the payer and the amount in cents.
4. Review open items daily against GET /v1/remits.

Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/remittance.md
- https://daybookhealthcare.com/docs/api-reference/remits/list.md
- https://daybookhealthcare.com/docs/api-reference/remits/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 /remits: List remits
- GET /remits/{id}: Retrieve a remit

Webhook events: remit.matched, payment.unmatched

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 finance works today (accounting system, spreadsheet or ticketing) and build the handler and daily job to feed it.
```

---

## Catch terminated coverage on open claims

When a patient's coverage changes, your product flags their open claims and visits, and can call the payer to confirm. Built on the Daybook API, with the steps, endpoints, events and a prompt for your AI assistant.

Source: https://daybookhealthcare.com/docs/use-cases/coverage-watch

[All use cases](https://daybookhealthcare.com/docs/use-cases.md)

- **For:** RCM and EHR vendors
- **Outcome:** When a patient's coverage changes, your product flags their open claims and visits, and can call the payer to confirm.
- **Workflows:** [Eligibility and benefits](https://daybookhealthcare.com/docs/workflows/eligibility.md), [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls.md)

### How it works

1. Run eligibility checks for patients with open claims or upcoming visits.
2. A re-check that finds different coverage sends coverage.changed.
3. Flag the patient's open claims and upcoming visits in your product.
4. Where the 271 leaves it unclear, start a payer call with call_type eligibility.

### Built on

- [`POST /v1/eligibility/checks`](https://daybookhealthcare.com/docs/api-reference/eligibility/create-check.md): Check eligibility
- [`POST /v1/calls`](https://daybookhealthcare.com/docs/api-reference/calls/create.md): Start a call

Events: `coverage.changed`, `eligibility.completed`, `call.completed`

### The prompt

```text
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: Catch terminated coverage on open claims
For: RCM and EHR vendors
Outcome: When a patient's coverage changes, your product flags their open claims and visits, and can call the payer to confirm.

What to build:
A coverage watch inside our product: scheduled eligibility checks with POST /v1/eligibility/checks for every patient with an open claim or an upcoming visit, a handler for coverage.changed that flags those claims and visits for the billing team, and a button on the flag that starts a payer call with POST /v1/calls (call_type eligibility) whose call.completed answer is shown on the patient.

How it works:
1. Run eligibility checks for patients with open claims or upcoming visits.
2. A re-check that finds different coverage sends coverage.changed.
3. Flag the patient's open claims and upcoming visits in your product.
4. Where the 271 leaves it unclear, start a payer call with call_type eligibility.

Read these docs first (Markdown):
- https://daybookhealthcare.com/docs/workflows/eligibility.md
- https://daybookhealthcare.com/docs/workflows/payer-calls.md
- https://daybookhealthcare.com/docs/api-reference/eligibility/create-check.md
- https://daybookhealthcare.com/docs/api-reference/calls/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):
- POST /eligibility/checks: Check eligibility
- POST /calls: Start a call

Webhook events: coverage.changed, eligibility.completed, call.completed

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 patients, claims and visits are stored in our product, then propose the flag and where it shows before writing code.
```

---

## Start a call

POST /v1/calls starts a payer call. Daybook works the phone tree, waits on hold and returns a structured answer.

Source: https://daybookhealthcare.com/docs/api-reference/calls/create

`POST https://api.daybookhealthcare.com/v1/calls`

The whole flow, with examples, is on [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls); read [Sandbox and payer calls](https://daybookhealthcare.com/docs/authentication#sandbox-and-payer-calls) before placing a call from a sandbox.

### Parameters

- `payer` (string, required): Daybook payer id, such as `bayline`, `keystone` or `meridian`.
- `call_type` (string, required): `claim_status`, `eligibility`, `prior_auth`, `appeal_status`, `payment_trace` or `other`.
- `mode` (string): `autonomous` (default for the five set call types) handles the call end to end. `handoff` rings the biller in `handoff` when a rep picks up and sends `call.handoff_ready`.
- `claim` (object): The claim the call is about. Required for `claim_status`, `appeal_status` and `payment_trace`.
  - `payer_claim_number` (string): The payer's claim number (ICN), when you have it.
  - `patient_control_number` (string): Your claim id as sent in CLM01.
  - `date_of_service` (string, required): First date of service, `YYYY-MM-DD`.
  - `billed_amount_cents` (integer): Total billed, in cents.
- `patient` (object, required): The member.
  - `first_name` (string, required)
  - `last_name` (string, required)
  - `date_of_birth` (string, required): `YYYY-MM-DD`.
  - `member_id` (string, required): Member id on the insurance card.
- `provider` (object, required): The provider the payer will verify.
  - `npi` (string, required): Billing or rendering NPI.
  - `tax_id` (string): Tax id, when the payer verifies by TIN.
- `questions` (string[]): Extra questions for the rep, asked after the standard ones for the call type.
- `script` (string): Id of one of your call scripts ([Worklists and rules](https://daybookhealthcare.com/docs/worklists-and-rules)). Daybook follows it in place of the default for the call type.
- `handoff` (object): Who to ring in for `handoff` calls.
  - `phone` (string, required): E.164 number Daybook bridges the rep to.
  - `name` (string): Biller name, for your logs.
- `schedule` (object): Repeat the call until something changes.
  - `repeat_every_days` (integer, required): Days between calls.
  - `until` (string): `status_changes` (default) or a date, `YYYY-MM-DD`.
- `metadata` (object): Up to 20 keys of your own: account, ticket, queue, work item. Echoed on the call and on every event about it, so your handler needs no lookup table. Ids only, never a patient's name, date of birth or member id.

### Example request body

```json
{
  "payer": "bayline",
  "call_type": "claim_status",
  "claim": {
    "patient_control_number": "A-10442-1",
    "date_of_service": "2026-09-14",
    "billed_amount_cents": 48500
  },
  "patient": {
    "first_name": "Jordan",
    "last_name": "Sample",
    "date_of_birth": "1980-01-01",
    "member_id": "W000000001"
  },
  "provider": {
    "npi": "1999999984"
  },
  "schedule": {
    "repeat_every_days": 5
  },
  "metadata": {
    "account": "A-10442",
    "ticket": "TCK-55821"
  }
}
```

### Response fields

- `id` (string): Unique id, prefixed `call_`.
- `object` (string): Always `call`.
- `status` (string): Where the call is, in order: `queued`, `dialing`, `navigating` (the phone tree), `on_hold`, `with_rep`, then `completed`, `failed` or `canceled`.
- `payer` (string): Daybook payer id.
- `call_type` (string): The call type you asked for.
- `mode` (string): `autonomous` or `handoff`.
- `hold_seconds` (integer): Time spent on hold so far.
- `claim` (object): The claim, as ids only: `patient_control_number` as you sent it and `payer_claim_number`, yours or the rep's. `null` without a claim.
- `handoff` (object): For a `handoff` call: your `phone` and `name`, and once a rep is on the line the `questions` and `rep_name`. `null` when autonomous.
- `answer` (object): The structured answer. `null` until the call completes.
  - `status` (string): What the rep said about the claim or member, normalized: for claim status, `paid`, `denied`, `pending`, `in_process` or `not_on_file`.
  - `reference_number` (string): The call reference the rep gave.
  - `rep_name` (string): The rep's name as given.
  - `next_step` (string): What to do next, in plain words.
  - `details` (object): Fields specific to the call type, such as `denial_reason`, `paid_amount_cents`, `check_number` or `auth_number`.
- `ended_reason` (string): Why a call ended short of an answer: your cancel's reason, or Daybook's in plain words (line busy, nobody answered the ring, hold ceiling passed). `null` otherwise.
- `transcript_url` (string): Signed link to the transcript. Expires after 1 hour. The same turns as [Read the transcript](https://daybookhealthcare.com/docs/api-reference/calls/transcript).
- `recording_url` (string): Signed link to the recording.
- `repeat_of` (string): The first call of a repeating series, when a `schedule` placed this call. `null` otherwise.
- `next_run_at` (string): When the next scheduled re-check runs, if the call repeats. `null` once the series stops.
- `metadata` (object): Your keys, echoed back.
- `created_at` (string): RFC 3339 timestamp.

### Example response

```json
{
  "id": "call_01JBX8M4Q2T7",
  "object": "call",
  "status": "queued",
  "payer": "bayline",
  "call_type": "claim_status",
  "mode": "autonomous",
  "hold_seconds": 0,
  "claim": {
    "patient_control_number": "A-10442-1",
    "payer_claim_number": null
  },
  "handoff": null,
  "answer": null,
  "ended_reason": null,
  "transcript_url": null,
  "recording_url": null,
  "repeat_of": null,
  "next_run_at": "2026-11-03T14:02:11Z",
  "metadata": {
    "account": "A-10442",
    "ticket": "TCK-55821"
  },
  "created_at": "2026-10-29T14:02:11Z"
}
```

---

## Retrieve a call

GET /v1/calls/{id}: fetch a payer call, its status and its structured answer once it completes.

Source: https://daybookhealthcare.com/docs/api-reference/calls/get

`GET https://api.daybookhealthcare.com/v1/calls/{id}`

Prefer `call.completed` over polling: it carries the same `answer` and your `metadata`. A finished call is also in **Payer calls** in the Daybook app with its transcript and captured fields, and the MCP tools `list_calls` and `get_call` read it; a completed call with a reference number also moves its claim to what the payer said. See [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls).

### Parameters

- `id` (string, required, in path): The call id.

### Response fields

- `id` (string): Unique id, prefixed `call_`.
- `object` (string): Always `call`.
- `status` (string): Where the call is, in order: `queued`, `dialing`, `navigating` (the phone tree), `on_hold`, `with_rep`, then `completed`, `failed` or `canceled`.
- `payer` (string): Daybook payer id.
- `call_type` (string): The call type you asked for.
- `mode` (string): `autonomous` or `handoff`.
- `hold_seconds` (integer): Time spent on hold so far.
- `claim` (object): The claim, as ids only: `patient_control_number` as you sent it and `payer_claim_number`, yours or the rep's. `null` without a claim.
- `handoff` (object): For a `handoff` call: your `phone` and `name`, and once a rep is on the line the `questions` and `rep_name`. `null` when autonomous.
- `answer` (object): The structured answer. `null` until the call completes.
  - `status` (string): What the rep said about the claim or member, normalized: for claim status, `paid`, `denied`, `pending`, `in_process` or `not_on_file`.
  - `reference_number` (string): The call reference the rep gave.
  - `rep_name` (string): The rep's name as given.
  - `next_step` (string): What to do next, in plain words.
  - `details` (object): Fields specific to the call type, such as `denial_reason`, `paid_amount_cents`, `check_number` or `auth_number`.
- `ended_reason` (string): Why a call ended short of an answer: your cancel's reason, or Daybook's in plain words (line busy, nobody answered the ring, hold ceiling passed). `null` otherwise.
- `transcript_url` (string): Signed link to the transcript. Expires after 1 hour. The same turns as [Read the transcript](https://daybookhealthcare.com/docs/api-reference/calls/transcript).
- `recording_url` (string): Signed link to the recording.
- `repeat_of` (string): The first call of a repeating series, when a `schedule` placed this call. `null` otherwise.
- `next_run_at` (string): When the next scheduled re-check runs, if the call repeats. `null` once the series stops.
- `metadata` (object): Your keys, echoed back.
- `created_at` (string): RFC 3339 timestamp.

### Example response

```json
{
  "id": "call_01JBX8M4Q2T7",
  "object": "call",
  "status": "completed",
  "payer": "bayline",
  "call_type": "claim_status",
  "mode": "autonomous",
  "hold_seconds": 1412,
  "claim": {
    "patient_control_number": "A-10442-1",
    "payer_claim_number": "BHP26288001144"
  },
  "handoff": null,
  "answer": {
    "status": "denied",
    "reference_number": "BHP-4471-0092",
    "rep_name": "Dana",
    "next_step": "Submit a retro authorization, then request reprocessing.",
    "details": {
      "denial_reason": "CO-197 precertification absent",
      "denied_on": "2026-10-02"
    }
  },
  "ended_reason": null,
  "transcript_url": "https://files.daybookhealthcare.com/t/call_01JBX8M4Q2T7?sig=...",
  "recording_url": null,
  "repeat_of": null,
  "next_run_at": null,
  "metadata": {
    "account": "A-10442",
    "ticket": "TCK-55821"
  },
  "created_at": "2026-10-29T14:02:11Z"
}
```

---

## List calls

GET /v1/calls: list payer calls by claim, status, payer, time window or your own metadata, newest first.

Source: https://daybookhealthcare.com/docs/api-reference/calls/list

`GET https://api.daybookhealthcare.com/v1/calls`

The list is how a queue reconciles: every call about one claim, every call still running, or the one call that carries your ticket id. In the Daybook app, the **Payer calls** page lists and searches calls by call id, claim id or reference number and filters them by what the payer answered, and the MCP tool `list_calls` lists them with an answer filter. See [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls).

### Parameters

- `claim` (string, in query): Calls about one claim, by the `patient_control_number` you sent.
- `status` (string, in query): One status, or several separated by commas. `queued,dialing,navigating,on_hold,with_rep` is every call still running.
- `payer` (string, in query): Daybook payer id.
- `call_type` (string, in query): `claim_status`, `eligibility`, `prior_auth`, `appeal_status`, `payment_trace` or `other`.
- `metadata[key]` (string, in query): Calls whose metadata `key` equals the value, such as `metadata[ticket]=TCK-55821`. One key per request.
- `created_after` (string, in query): RFC 3339. Calls created at or after this instant.
- `created_before` (string, in query): RFC 3339. Calls created before this instant.
- `limit` (integer, in query): 1 to 100. Default 20.
- `starting_after` (string, in query): The last id of the page before, for the next page.

### Response fields

- `data` (object[]): Call objects, as [Retrieve a call](https://daybookhealthcare.com/docs/api-reference/calls/get) returns them, newest first.
- `has_more` (boolean): Whether another page follows. Pass the last id as `starting_after`.

### Example response

```json
{
  "data": [
    {
      "id": "call_01JBX8M4Q2T7",
      "object": "call",
      "status": "completed",
      "payer": "bayline",
      "call_type": "claim_status",
      "mode": "autonomous",
      "hold_seconds": 1412,
      "claim": {
        "patient_control_number": "A-10442-1",
        "payer_claim_number": "BHP26288001144"
      },
      "handoff": null,
      "answer": {
        "status": "denied",
        "reference_number": "BHP-4471-0092",
        "rep_name": "Dana",
        "next_step": "Submit a retro authorization, then request reprocessing.",
        "details": {
          "denial_reason": "CO-197 precertification absent"
        }
      },
      "ended_reason": null,
      "transcript_url": "https://files.daybookhealthcare.com/t/call_01JBX8M4Q2T7?sig=...",
      "recording_url": null,
      "repeat_of": null,
      "next_run_at": null,
      "metadata": {
        "account": "A-10442",
        "ticket": "TCK-55821",
        "queue": "denials"
      },
      "created_at": "2026-10-29T14:02:11Z"
    }
  ],
  "has_more": false
}
```

---

## Cancel a call

POST /v1/calls/{id}/cancel: stop a payer call before it dials, end a live one, or stop a repeating series.

Source: https://daybookhealthcare.com/docs/api-reference/calls/cancel

`POST https://api.daybookhealthcare.com/v1/calls/{id}/cancel`

Cancel is how your queue closes the loop from its side: the claim paid on the 835 before the call went out, a person already called, the ticket was closed. The call answers with `status` `canceled` and your `reason` in `ended_reason`, and `call.canceled` goes to your endpoints. A call that has already ended answers `409 conflict`. In the Daybook app, **Hang up** on the **Live calls** page does the same for a call on the line, for the item's owner and the firm's leads. See [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls).

### Parameters

- `id` (string, required, in path): The call id. For a repeating series, any call in it stops the series.
- `reason` (string): Why, for the call's record and your logs. Up to 200 characters. Never spoken on the call.

### Example request body

```json
{
  "reason": "Paid on the 835 of 2026-10-30"
}
```

### Response fields

- `id` (string): Unique id, prefixed `call_`.
- `object` (string): Always `call`.
- `status` (string): Where the call is, in order: `queued`, `dialing`, `navigating` (the phone tree), `on_hold`, `with_rep`, then `completed`, `failed` or `canceled`.
- `ended_reason` (string): Why the call ended short of an answer. For a cancel, the `reason` you sent.
- `metadata` (object): Your keys, echoed back.

### Example response

```json
{
  "id": "call_01JBX8M4Q2T7",
  "object": "call",
  "status": "canceled",
  "payer": "bayline",
  "call_type": "claim_status",
  "mode": "autonomous",
  "hold_seconds": 0,
  "claim": {
    "patient_control_number": "A-10442-1",
    "payer_claim_number": null
  },
  "handoff": null,
  "answer": null,
  "ended_reason": "Paid on the 835 of 2026-10-30",
  "transcript_url": null,
  "recording_url": null,
  "repeat_of": null,
  "next_run_at": null,
  "metadata": {
    "account": "A-10442",
    "ticket": "TCK-55821"
  },
  "created_at": "2026-10-29T14:02:11Z"
}
```

---

## Tell the agent something

POST /v1/calls/{id}/instruct: send Daybook's voice agent a note while a payer call is live. Never spoken aloud.

Source: https://daybookhealthcare.com/docs/api-reference/calls/instruct

`POST https://api.daybookhealthcare.com/v1/calls/{id}/instruct`

A note to the agent from your tool while the call is up: a biller watching the ticket adds "ask for the check number", or your system learns mid-call that the member's plan changed. The line shows in the transcript as an operator note and the agent works it into the conversation. It takes a call from `dialing` to `with_rep`; a call that has ended answers `409 conflict`. **Tell the agent** in the Daybook app's **Live calls** does the same, for the item's owner and the firm's leads, up to 280 characters. See [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls).

### Parameters

- `id` (string, required, in path): The call id.
- `text` (string, required): What the agent should know or ask. Up to 280 characters. Never said on the call as written.

### Example request body

```json
{
  "text": "Ask for the check number and the date it was mailed."
}
```

### Response fields

- `id` (string): The call id.
- `object` (string): Always `call`.
- `status` (string): Where the call is now.
- `instructions` (object[]): Every line sent to the agent on this call, oldest first: `text` and `at`.

### Example response

```json
{
  "id": "call_01JBX8M4Q2T7",
  "object": "call",
  "status": "with_rep",
  "instructions": [
    {
      "text": "Ask for the check number and the date it was mailed.",
      "at": "2026-10-29T14:28:03Z"
    }
  ]
}
```

---

## Read the transcript

GET /v1/calls/{id}/transcript: read a payer call turn by turn, with the speaker and timing of each line.

Source: https://daybookhealthcare.com/docs/api-reference/calls/transcript

`GET https://api.daybookhealthcare.com/v1/calls/{id}/transcript`

The transcript is the artifact a CRM keeps beside the answer: what the rep said, in the rep's words, with the phone tree, the hold and any note you sent the agent. The transcript is also on the call in the Daybook app, in **Live calls** as it happens and in **Payer calls** after, and the MCP tool `get_call` returns the turns. See [Payer calls](https://daybookhealthcare.com/docs/workflows/payer-calls).

### Parameters

- `id` (string, required, in path): The call id.

### Response fields

- `call` (string): The call id.
- `status` (string): Where the call is. A transcript grows while the call runs.
- `turns` (object[]): In order.
  - `at_ms` (integer): Milliseconds from the start of the call.
  - `speaker` (string): `agent`, `rep`, `phone_tree`, `person` (a biller who took the call over or was rung in), `operator` (a note sent to the agent, never said on the call) or `event` (a key pressed, the hold, the rep joining, a hang-up).
  - `text` (string)
- `recording_url` (string): Signed link to the recording.

### Example response

```json
{
  "call": "call_01JBX8M4Q2T7",
  "status": "completed",
  "turns": [
    {
      "at_ms": 0,
      "speaker": "event",
      "text": "Dialing Bayline Health Plan, (800) 555-0142"
    },
    {
      "at_ms": 4200,
      "speaker": "phone_tree",
      "text": "Thank you for calling Bayline provider services. For claims, press 2."
    },
    {
      "at_ms": 6100,
      "speaker": "event",
      "text": "Pressed 2"
    },
    {
      "at_ms": 61000,
      "speaker": "event",
      "text": "On hold"
    },
    {
      "at_ms": 1473000,
      "speaker": "rep",
      "text": "Provider services, this is Dana."
    },
    {
      "at_ms": 1476500,
      "speaker": "agent",
      "text": "Hi Dana, I am calling for Lantern Creek Family Medicine about claim A-10442-1, date of service September 14."
    },
    {
      "at_ms": 1512000,
      "speaker": "rep",
      "text": "That claim denied on October 2, CO-197, no precertification on file."
    },
    {
      "at_ms": 1515000,
      "speaker": "operator",
      "text": "Ask whether a retro authorization would be accepted."
    },
    {
      "at_ms": 1530000,
      "speaker": "agent",
      "text": "Would a retro authorization be accepted, and may I have a reference number for this call?"
    },
    {
      "at_ms": 1552000,
      "speaker": "rep",
      "text": "Yes, within 60 days of the denial. Reference BHP-4471-0092."
    }
  ],
  "recording_url": null
}
```

---

## Start a portal task

POST /v1/portal-tasks has Daybook sign in to a payer portal, run a defined set of steps and read the result back. Part of the payer portals workflow.

Source: https://daybookhealthcare.com/docs/api-reference/portal-tasks/create

`POST https://api.daybookhealthcare.com/v1/portal-tasks`

### Parameters

- `payer` (string, required): Daybook payer id.
- `task` (string, required): `remit_lookup`, `claim_lookup`, `appeal_status`, `attachment_upload` or `overpayment_lookup`.
- `portal` (string): Force a portal. By default Daybook picks the portal that answers the task for this payer.
- `claim` (object): The claim the task is about.
  - `payer_claim_number` (string): The payer's claim number (ICN), when you have it.
  - `patient_control_number` (string): Your claim id as sent in CLM01.
  - `date_of_service` (string, required): First date of service, `YYYY-MM-DD`.
  - `billed_amount_cents` (integer): Total billed, in cents.
- `provider` (object, required): The provider whose portal account to use.
  - `npi` (string, required): Billing or rendering NPI.
  - `tax_id` (string): Tax id, when the payer verifies by TIN.
- `attachment_url` (string): For `attachment_upload`: an HTTPS link Daybook fetches the file from.
- `require_approval` (boolean): Hold any step that changes something in the portal until you approve it. Defaults to `true` for `attachment_upload`.
- `metadata` (object): Your keys, echoed back.

### Example request body

```json
{
  "payer": "keystone",
  "task": "remit_lookup",
  "claim": {
    "patient_control_number": "A-20817-1",
    "date_of_service": "2026-09-30"
  },
  "provider": {
    "npi": "1999999984",
    "tax_id": "00-0000000"
  }
}
```

### Response fields

- `id` (string): Unique id, prefixed `ptask_`.
- `object` (string): Always `portal_task`.
- `status` (string): `queued`, `running`, `approval_required`, `completed`, `failed` or `canceled`.
- `payer` (string): Daybook payer id.
- `portal` (string): The portal used, such as `availity` or the payer's own site.
- `task` (string): The task you asked for.
- `pending_action` (object): What Daybook is about to change in the portal. Present while `approval_required`.
  - `summary` (string): The change, in plain words.
  - `screenshot_url` (string): Signed link to the screen as it will be submitted.
- `result` (object): What Daybook read back. Shape depends on `task`. `null` until completed.
- `evidence` (object[]): Signed links to the pages captured along the way.
- `metadata` (object): Your keys, echoed back.
- `created_at` (string): RFC 3339 timestamp.

### Example response

```json
{
  "id": "ptask_01JBXA2W8K3N",
  "object": "portal_task",
  "status": "queued",
  "payer": "keystone",
  "portal": "availity",
  "task": "remit_lookup",
  "pending_action": null,
  "result": null,
  "evidence": [],
  "metadata": {},
  "created_at": "2026-10-29T15:10:40Z"
}
```

---

## Retrieve a portal task

GET /v1/portal-tasks/{id} fetches a payer portal task with its pending action and its result, once it has one. Part of the payer portals workflow.

Source: https://daybookhealthcare.com/docs/api-reference/portal-tasks/get

`GET https://api.daybookhealthcare.com/v1/portal-tasks/{id}`

### Parameters

- `id` (string, required, in path): The portal task id.

### Response fields

- `id` (string): Unique id, prefixed `ptask_`.
- `object` (string): Always `portal_task`.
- `status` (string): `queued`, `running`, `approval_required`, `completed`, `failed` or `canceled`.
- `payer` (string): Daybook payer id.
- `portal` (string): The portal used, such as `availity` or the payer's own site.
- `task` (string): The task you asked for.
- `pending_action` (object): What Daybook is about to change in the portal. Present while `approval_required`.
  - `summary` (string): The change, in plain words.
  - `screenshot_url` (string): Signed link to the screen as it will be submitted.
- `result` (object): What Daybook read back. Shape depends on `task`. `null` until completed.
- `evidence` (object[]): Signed links to the pages captured along the way.
- `metadata` (object): Your keys, echoed back.
- `created_at` (string): RFC 3339 timestamp.

### Example response

```json
{
  "id": "ptask_01JBXA2W8K3N",
  "object": "portal_task",
  "status": "completed",
  "payer": "keystone",
  "portal": "availity",
  "task": "remit_lookup",
  "pending_action": null,
  "result": {
    "check_or_eft_number": "EFT00048213",
    "payment_date": "2026-10-21",
    "payment_amount_cents": 31200,
    "era_url": "https://files.daybookhealthcare.com/r/ptask_01JBXA2W8K3N/835?sig=..."
  },
  "evidence": [
    {
      "label": "Remittance viewer",
      "url": "https://files.daybookhealthcare.com/e/ptask_01JBXA2W8K3N/1?sig=..."
    }
  ],
  "metadata": {},
  "created_at": "2026-10-29T15:10:40Z"
}
```

---

## Approve a portal action

POST /v1/portal-tasks/{id}/approve lets a held payer portal action go through, or rejects it, while it waits for approval. Part of the portals workflow.

Source: https://daybookhealthcare.com/docs/api-reference/portal-tasks/approve

`POST https://api.daybookhealthcare.com/v1/portal-tasks/{id}/approve`

### Parameters

- `id` (string, required, in path): The portal task id.
- `decision` (string, required): `approve` or `reject`.
- `note` (string): Kept on the task's audit trail.

### Example request body

```json
{
  "decision": "approve",
  "note": "Checked the attachment, send it."
}
```

### Response fields

- `id` (string): Unique id, prefixed `ptask_`.
- `object` (string): Always `portal_task`.
- `status` (string): `queued`, `running`, `approval_required`, `completed`, `failed` or `canceled`.
- `payer` (string): Daybook payer id.
- `portal` (string): The portal used, such as `availity` or the payer's own site.
- `task` (string): The task you asked for.
- `pending_action` (object): What Daybook is about to change in the portal. Present while `approval_required`.
  - `summary` (string): The change, in plain words.
  - `screenshot_url` (string): Signed link to the screen as it will be submitted.
- `result` (object): What Daybook read back. Shape depends on `task`. `null` until completed.
- `evidence` (object[]): Signed links to the pages captured along the way.
- `metadata` (object): Your keys, echoed back.
- `created_at` (string): RFC 3339 timestamp.

### Example response

```json
{
  "id": "ptask_01JBXA2W8K3N",
  "object": "portal_task",
  "status": "running",
  "payer": "keystone",
  "portal": "availity",
  "task": "attachment_upload",
  "pending_action": null,
  "result": null,
  "evidence": [
    {
      "label": "Remittance viewer",
      "url": "https://files.daybookhealthcare.com/e/ptask_01JBXA2W8K3N/1?sig=..."
    }
  ],
  "metadata": {},
  "created_at": "2026-10-29T15:10:40Z"
}
```

---

## Submit an enrollment

POST /v1/enrollments enrolls a provider with a payer for electronic remits (ERA), electronic payments (EFT) or both. Part of the enrollment workflow.

Source: https://daybookhealthcare.com/docs/api-reference/enrollments/create

`POST https://api.daybookhealthcare.com/v1/enrollments`

### Parameters

- `payer` (string, required): Daybook payer id.
- `transactions` (string[], required): `era`, `eft` or both.
- `provider` (object, required): The provider to enroll.
  - `npi` (string, required)
  - `tax_id` (string, required)
  - `name` (string, required): Legal name as the payer has it.
- `bank_account` (object): Required for `eft`.
  - `routing_number` (string, required)
  - `account_number` (string, required)
  - `account_type` (string, required): `checking` or `savings`.
- `contact` (object, required): Who the payer contacts about the enrollment.
  - `name` (string, required)
  - `email` (string, required)
  - `phone` (string)
- `metadata` (object): Your keys, echoed back.

### Example request body

```json
{
  "payer": "meridian",
  "transactions": [
    "era",
    "eft"
  ],
  "provider": {
    "npi": "1999999984",
    "tax_id": "00-0000000",
    "name": "Sample Family Dental"
  },
  "bank_account": {
    "routing_number": "000000000",
    "account_number": "000000000000",
    "account_type": "checking"
  },
  "contact": {
    "name": "Alex Biller",
    "email": "billing@example.com"
  }
}
```

### Response fields

- `id` (string): Unique id, prefixed `enr_`.
- `object` (string): Always `enrollment`.
- `status` (string): `submitted`, `pending_payer`, `action_required`, `approved` or `rejected`.
- `payer` (string): Daybook payer id.
- `transactions` (string[]): `era`, `eft` or both.
- `provider` (object): The enrolled provider.
- `action_required` (object): What the payer is waiting on. Present while `action_required`.
  - `type` (string): `signature`, `document`, `verification_letter` or `contact`.
  - `description` (string): What the payer asked for, in plain words.
  - `due_by` (string): The payer's deadline, when it gave one.
- `approved_at` (string): When the payer confirmed the enrollment.
- `metadata` (object): Your keys, echoed back.
- `created_at` (string): RFC 3339 timestamp.

### Example response

```json
{
  "id": "enr_01JBXC7F2D9R",
  "object": "enrollment",
  "status": "submitted",
  "payer": "meridian",
  "transactions": [
    "era",
    "eft"
  ],
  "provider": {
    "npi": "1999999984",
    "tax_id": "00-0000000",
    "name": "Sample Family Dental"
  },
  "action_required": null,
  "approved_at": null,
  "metadata": {},
  "created_at": "2026-10-20T13:00:00Z"
}
```

---

## Retrieve an enrollment

GET /v1/enrollments/{id} fetches an ERA or EFT enrollment, its status and whatever the payer is waiting on. Part of the ERA and EFT enrollment workflow.

Source: https://daybookhealthcare.com/docs/api-reference/enrollments/get

`GET https://api.daybookhealthcare.com/v1/enrollments/{id}`

### Parameters

- `id` (string, required, in path): The enrollment id.

### Response fields

- `id` (string): Unique id, prefixed `enr_`.
- `object` (string): Always `enrollment`.
- `status` (string): `submitted`, `pending_payer`, `action_required`, `approved` or `rejected`.
- `payer` (string): Daybook payer id.
- `transactions` (string[]): `era`, `eft` or both.
- `provider` (object): The enrolled provider.
- `action_required` (object): What the payer is waiting on. Present while `action_required`.
  - `type` (string): `signature`, `document`, `verification_letter` or `contact`.
  - `description` (string): What the payer asked for, in plain words.
  - `due_by` (string): The payer's deadline, when it gave one.
- `approved_at` (string): When the payer confirmed the enrollment.
- `metadata` (object): Your keys, echoed back.
- `created_at` (string): RFC 3339 timestamp.

### Example response

```json
{
  "id": "enr_01JBXC7F2D9R",
  "object": "enrollment",
  "status": "action_required",
  "payer": "meridian",
  "transactions": [
    "era",
    "eft"
  ],
  "provider": {
    "npi": "1999999984",
    "tax_id": "00-0000000",
    "name": "Sample Family Dental"
  },
  "action_required": {
    "type": "verification_letter",
    "description": "Upload a bank letter confirming the account for EFT.",
    "due_by": "2026-11-12"
  },
  "approved_at": null,
  "metadata": {},
  "created_at": "2026-10-20T13:00:00Z"
}
```

---

## Check eligibility

POST /v1/eligibility/checks runs a real-time 270/271 eligibility and benefits check with the payer. Part of the eligibility and benefits workflow.

Source: https://daybookhealthcare.com/docs/api-reference/eligibility/create-check

`POST https://api.daybookhealthcare.com/v1/eligibility/checks`

Send up to 1,000 checks at once to `POST /v1/eligibility/checks/batch` with a `checks` array of the same objects. Batches return `pending` and each result arrives as an `eligibility.completed` event.

### Parameters

- `payer` (string, required): Daybook payer id.
- `provider` (object, required)
  - `npi` (string, required): Billing or rendering NPI.
  - `tax_id` (string): Tax id, when the payer verifies by TIN.
- `patient` (object, required)
  - `first_name` (string, required)
  - `last_name` (string, required)
  - `date_of_birth` (string, required): `YYYY-MM-DD`.
  - `member_id` (string, required): Member id on the insurance card.
- `date_of_service` (string): Defaults to today.
- `service_type_codes` (string[]): X12 service type codes. Defaults to `["30"]`.

### Example request body

```json
{
  "payer": "bayline",
  "provider": {
    "npi": "1999999984"
  },
  "patient": {
    "first_name": "Jordan",
    "last_name": "Sample",
    "date_of_birth": "1980-01-01",
    "member_id": "W000000001"
  },
  "service_type_codes": [
    "30"
  ]
}
```

### Response fields

- `id` (string): Unique id, prefixed `elig_`.
- `object` (string): Always `eligibility_check`.
- `status` (string): `complete`, `pending` (batches) or `failed`.
- `coverage` (object): From the 271.
  - `active` (boolean): Whether coverage is active on the date of service.
  - `plan_name` (string)
  - `group_number` (string)
  - `coverage_start` (string)
  - `coverage_end` (string)
- `benefits` (object): Amounts in cents for the service types asked about.
  - `deductible_remaining_cents` (integer)
  - `out_of_pocket_remaining_cents` (integer)
  - `copay_cents` (integer)
  - `coinsurance_percent` (integer)
- `errors` (object[]): AAA rejections from the payer, with code and plain-words reason.
- `raw_271_url` (string): Signed link to the 271 as received.
- `created_at` (string): RFC 3339 timestamp.

### Example response

```json
{
  "id": "elig_01JBXD0P6Y1S",
  "object": "eligibility_check",
  "status": "complete",
  "coverage": {
    "active": true,
    "plan_name": "Bayline Choice PPO",
    "group_number": "000000",
    "coverage_start": "2026-01-01",
    "coverage_end": null
  },
  "benefits": {
    "deductible_remaining_cents": 42000,
    "out_of_pocket_remaining_cents": 310000,
    "copay_cents": 3000,
    "coinsurance_percent": 20
  },
  "errors": [],
  "raw_271_url": "https://files.daybookhealthcare.com/x/elig_01JBXD0P6Y1S/271?sig=...",
  "created_at": "2026-10-29T15:22:05Z"
}
```

---

## Check claim status

POST /v1/claim-status/checks runs a real-time 276/277 claim status check with the payer, one claim at a time or in batches. Part of claim status.

Source: https://daybookhealthcare.com/docs/api-reference/claim-status/create-check

`POST https://api.daybookhealthcare.com/v1/claim-status/checks`

For volume, send up to 1,000 checks to `POST /v1/claim-status/checks/batch`, or let a [rule](https://daybookhealthcare.com/docs/api-reference/rules/create) start them for you, such as every claim with no response in 30 days.

### Parameters

- `payer` (string, required): Daybook payer id.
- `provider` (object, required)
  - `npi` (string, required): Billing or rendering NPI.
  - `tax_id` (string): Tax id, when the payer verifies by TIN.
- `patient` (object, required)
  - `first_name` (string, required)
  - `last_name` (string, required)
  - `date_of_birth` (string, required): `YYYY-MM-DD`.
  - `member_id` (string, required): Member id on the insurance card.
- `claim` (object, required)
  - `payer_claim_number` (string): The payer's claim number (ICN), when you have it.
  - `patient_control_number` (string): Your claim id as sent in CLM01.
  - `date_of_service` (string, required): First date of service, `YYYY-MM-DD`.
  - `billed_amount_cents` (integer): Total billed, in cents.

### Example request body

```json
{
  "payer": "keystone",
  "provider": {
    "npi": "1999999984",
    "tax_id": "00-0000000"
  },
  "patient": {
    "first_name": "Jordan",
    "last_name": "Sample",
    "date_of_birth": "1980-01-01",
    "member_id": "W000000001"
  },
  "claim": {
    "patient_control_number": "A-20817-1",
    "date_of_service": "2026-09-30",
    "billed_amount_cents": 41000
  }
}
```

### Response fields

- `id` (string): Unique id, prefixed `cs_`.
- `object` (string): Always `claim_status_check`.
- `status` (string): `complete`, `pending` (batches) or `failed`.
- `claim_status` (object): From the 277.
  - `category` (string): Normalized: `paid`, `denied`, `pending`, `in_process`, `returned` or `not_on_file`.
  - `category_code` (string): X12 claim status category code, such as `F1` or `A2`.
  - `status_code` (string): X12 claim status code.
  - `effective_date` (string)
  - `paid_amount_cents` (integer)
  - `check_or_eft_number` (string)
  - `payer_claim_number` (string)
- `changed` (boolean): Whether the status differs from the last check on this claim.
- `raw_277_url` (string): Signed link to the 277 as received.
- `created_at` (string): RFC 3339 timestamp.

### Example response

```json
{
  "id": "cs_01JBXE4H9M2T",
  "object": "claim_status_check",
  "status": "complete",
  "claim_status": {
    "category": "paid",
    "category_code": "F1",
    "status_code": "65",
    "effective_date": "2026-10-21",
    "paid_amount_cents": 31200,
    "check_or_eft_number": "EFT00048213",
    "payer_claim_number": "2026294000123"
  },
  "changed": true,
  "raw_277_url": "https://files.daybookhealthcare.com/x/cs_01JBXE4H9M2T/277?sig=...",
  "created_at": "2026-10-29T15:30:00Z"
}
```

---

## List remits

GET /v1/remits lists the 835 remits Daybook has pulled for you, newest first, ready to match and post. Part of the remittance and posting workflow.

Source: https://daybookhealthcare.com/docs/api-reference/remits/list

`GET https://api.daybookhealthcare.com/v1/remits`

### Parameters

- `payer` (string, in query): Only this payer.
- `received_after` (string, in query): RFC 3339 timestamp.
- `match` (string, in query): `matched` or `unmatched`.
- `limit` (integer, in query): 1 to 100. Defaults to 25.
- `starting_after` (string, in query): Cursor: a remit id from the previous page.

### Response fields

- `data` (object[]): Remit objects.
- `has_more` (boolean)

### Example response

```json
{
  "data": [
    {
      "id": "remit_01JBXF8B3C4V",
      "object": "remit",
      "payer": "keystone",
      "check_or_eft_number": "EFT00048213",
      "payment_amount_cents": 31200,
      "payment_date": "2026-10-21",
      "deposit": {
        "id": "dep_01JBX9",
        "amount_cents": 31200,
        "posted_on": "2026-10-22"
      },
      "claims": [
        {
          "patient_control_number": "A-20817-1",
          "billed_cents": 41000,
          "allowed_cents": 34200,
          "paid_cents": 31200,
          "patient_responsibility_cents": 3000,
          "adjustments": [
            {
              "group": "CO",
              "carc": "45",
              "amount_cents": 6800
            },
            {
              "group": "PR",
              "carc": "3",
              "amount_cents": 3000
            }
          ],
          "remark_codes": [],
          "matched_claim": "A-20817-1",
          "denial": null
        }
      ],
      "posting": {
        "status": "proposed",
        "entries": [
          {
            "type": "payment",
            "claim": "A-20817-1",
            "amount_cents": 31200
          },
          {
            "type": "adjustment",
            "claim": "A-20817-1",
            "code": "CO-45",
            "amount_cents": 6800
          },
          {
            "type": "transfer_to_patient",
            "claim": "A-20817-1",
            "amount_cents": 3000
          }
        ]
      },
      "raw_835_url": "https://files.daybookhealthcare.com/x/remit_01JBXF8B3C4V/835?sig=..."
    }
  ],
  "has_more": false
}
```

---

## Retrieve a remit

GET /v1/remits/{id} fetches an 835 remit with its claim lines, its deposit match and the proposed posting. Part of the remittance and posting workflow.

Source: https://daybookhealthcare.com/docs/api-reference/remits/get

`GET https://api.daybookhealthcare.com/v1/remits/{id}`

### Parameters

- `id` (string, required, in path): The remit id.

### Response fields

- `id` (string): Unique id, prefixed `remit_`.
- `object` (string): Always `remit`.
- `payer` (string): Daybook payer id.
- `check_or_eft_number` (string): TRN02 trace number.
- `payment_amount_cents` (integer): BPR02 total payment.
- `payment_date` (string)
- `deposit` (object): The bank deposit the payment matched, or `null`.
  - `id` (string)
  - `amount_cents` (integer)
  - `posted_on` (string)
- `claims` (object[]): One entry per CLP loop.
  - `patient_control_number` (string)
  - `billed_cents` (integer)
  - `allowed_cents` (integer)
  - `paid_cents` (integer)
  - `patient_responsibility_cents` (integer)
  - `adjustments` (object[]): Group code, CARC and amount for each CAS adjustment.
  - `remark_codes` (string[]): RARCs.
  - `matched_claim` (string): Your claim id, when matched.
  - `denial` (string): Denial id, when the line was denied. See [Retrieve a denial](https://daybookhealthcare.com/docs/api-reference/denials/get).
- `posting` (object): The proposed posting.
  - `status` (string): `proposed`, `approved` or `rejected`.
  - `entries` (object[]): Payment, adjustment and transfer entries, ready for your PM system.
- `raw_835_url` (string): Signed link to the 835 as received.

### Example response

```json
{
  "id": "remit_01JBXF8B3C4V",
  "object": "remit",
  "payer": "keystone",
  "check_or_eft_number": "EFT00048213",
  "payment_amount_cents": 31200,
  "payment_date": "2026-10-21",
  "deposit": {
    "id": "dep_01JBX9",
    "amount_cents": 31200,
    "posted_on": "2026-10-22"
  },
  "claims": [
    {
      "patient_control_number": "A-20817-1",
      "billed_cents": 41000,
      "allowed_cents": 34200,
      "paid_cents": 31200,
      "patient_responsibility_cents": 3000,
      "adjustments": [
        {
          "group": "CO",
          "carc": "45",
          "amount_cents": 6800
        },
        {
          "group": "PR",
          "carc": "3",
          "amount_cents": 3000
        }
      ],
      "remark_codes": [],
      "matched_claim": "A-20817-1",
      "denial": null
    }
  ],
  "posting": {
    "status": "proposed",
    "entries": [
      {
        "type": "payment",
        "claim": "A-20817-1",
        "amount_cents": 31200
      },
      {
        "type": "adjustment",
        "claim": "A-20817-1",
        "code": "CO-45",
        "amount_cents": 6800
      },
      {
        "type": "transfer_to_patient",
        "claim": "A-20817-1",
        "amount_cents": 3000
      }
    ]
  },
  "raw_835_url": "https://files.daybookhealthcare.com/x/remit_01JBXF8B3C4V/835?sig=..."
}
```

---

## Approve a posting

POST /v1/remits/{id}/posting/approve approves or rejects a remit's proposed posting and fires posting.approved for your write-back to pick up.

Source: https://daybookhealthcare.com/docs/api-reference/remits/approve-posting

`POST https://api.daybookhealthcare.com/v1/remits/{id}/posting/approve`

### Parameters

- `id` (string, required, in path): The remit id.
- `decision` (string, required): `approve` or `reject`.
- `note` (string): Kept on the audit trail.

### Example request body

```json
{
  "decision": "approve"
}
```

### Response fields

- `id` (string): Unique id, prefixed `remit_`.
- `object` (string): Always `remit`.
- `payer` (string): Daybook payer id.
- `check_or_eft_number` (string): TRN02 trace number.
- `payment_amount_cents` (integer): BPR02 total payment.
- `payment_date` (string)
- `deposit` (object): The bank deposit the payment matched, or `null`.
  - `id` (string)
  - `amount_cents` (integer)
  - `posted_on` (string)
- `claims` (object[]): One entry per CLP loop.
  - `patient_control_number` (string)
  - `billed_cents` (integer)
  - `allowed_cents` (integer)
  - `paid_cents` (integer)
  - `patient_responsibility_cents` (integer)
  - `adjustments` (object[]): Group code, CARC and amount for each CAS adjustment.
  - `remark_codes` (string[]): RARCs.
  - `matched_claim` (string): Your claim id, when matched.
  - `denial` (string): Denial id, when the line was denied. See [Retrieve a denial](https://daybookhealthcare.com/docs/api-reference/denials/get).
- `posting` (object): The proposed posting.
  - `status` (string): `proposed`, `approved` or `rejected`.
  - `entries` (object[]): Payment, adjustment and transfer entries, ready for your PM system.
- `raw_835_url` (string): Signed link to the 835 as received.

### Example response

```json
{
  "id": "remit_01JBXF8B3C4V",
  "object": "remit",
  "payer": "keystone",
  "check_or_eft_number": "EFT00048213",
  "payment_amount_cents": 31200,
  "payment_date": "2026-10-21",
  "deposit": {
    "id": "dep_01JBX9",
    "amount_cents": 31200,
    "posted_on": "2026-10-22"
  },
  "claims": [
    {
      "patient_control_number": "A-20817-1",
      "billed_cents": 41000,
      "allowed_cents": 34200,
      "paid_cents": 31200,
      "patient_responsibility_cents": 3000,
      "adjustments": [
        {
          "group": "CO",
          "carc": "45",
          "amount_cents": 6800
        },
        {
          "group": "PR",
          "carc": "3",
          "amount_cents": 3000
        }
      ],
      "remark_codes": [],
      "matched_claim": "A-20817-1",
      "denial": null
    }
  ],
  "posting": {
    "status": "approved",
    "entries": [
      {
        "type": "payment",
        "claim": "A-20817-1",
        "amount_cents": 31200
      },
      {
        "type": "adjustment",
        "claim": "A-20817-1",
        "code": "CO-45",
        "amount_cents": 6800
      },
      {
        "type": "transfer_to_patient",
        "claim": "A-20817-1",
        "amount_cents": 3000
      }
    ]
  },
  "raw_835_url": "https://files.daybookhealthcare.com/x/remit_01JBXF8B3C4V/835?sig=..."
}
```

---

## Retrieve a denial

GET /v1/denials/{id} fetches a denial with its codes, the cause Daybook sorted it into and the recommended next step. Part of denials and appeals.

Source: https://daybookhealthcare.com/docs/api-reference/denials/get

`GET https://api.daybookhealthcare.com/v1/denials/{id}`

### Parameters

- `id` (string, required, in path): The denial id.

### Response fields

- `id` (string): Unique id, prefixed `den_`.
- `object` (string): Always `denial`.
- `remit` (string): The remit the denial came on.
- `claim` (string): Your claim id.
- `codes` (object)
  - `group` (string): CAS group code.
  - `carc` (string)
  - `rarc` (string[])
- `cause` (string): `missing_auth`, `eligibility`, `coding`, `timely_filing`, `duplicate`, `medical_necessity`, `coordination_of_benefits`, `credentialing`, `bundling` or `other`.
- `cause_detail` (string): Why Daybook sorted it there, in plain words.
- `recommended_action` (string): `appeal`, `correct_and_resubmit`, `call_payer`, `bill_patient`, `bill_secondary` or `write_off`.
- `appealable` (boolean)
- `appeal_deadline` (string): From the payer's filing limit, when known.
- `amount_cents` (integer): Amount denied.

### Example response

```json
{
  "id": "den_01JBXG2N5R8W",
  "object": "denial",
  "remit": "remit_01JBXF8B3C4V",
  "claim": "A-31120-1",
  "codes": {
    "group": "CO",
    "carc": "197",
    "rarc": [
      "N54"
    ]
  },
  "cause": "missing_auth",
  "cause_detail": "Precertification was required for D4341 and none was on file.",
  "recommended_action": "appeal",
  "appealable": true,
  "appeal_deadline": "2027-04-19",
  "amount_cents": 88000
}
```

---

## Draft an appeal

POST /v1/appeals drafts an appeal letter from a denial's data, for a biller to review and send to the payer. Part of the denials and appeals workflow.

Source: https://daybookhealthcare.com/docs/api-reference/appeals/create

`POST https://api.daybookhealthcare.com/v1/appeals`

### Parameters

- `denial` (string, required): The denial id.
- `supporting_documents` (string[]): HTTPS links Daybook may cite, such as the auth approval or chart notes.
- `signer` (object): Name and title for the signature block.

### Example request body

```json
{
  "denial": "den_01JBXG2N5R8W",
  "signer": {
    "name": "Alex Biller",
    "title": "Billing Manager"
  }
}
```

### Response fields

- `id` (string): Unique id, prefixed `apl_`.
- `object` (string): Always `appeal`.
- `status` (string): `drafting`, `ready` or `refused`.
- `denial` (string): The denial id.
- `letter` (object): Present when `ready`.
  - `text` (string): The letter as plain text.
  - `pdf_url` (string): Signed link to the PDF.
- `refused_reason` (string): Present when `refused`: why the denial should not be appealed, with the figures behind it.
- `created_at` (string): RFC 3339 timestamp.

### Example response

```json
{
  "id": "apl_01JBXH6Q0T3Y",
  "object": "appeal",
  "status": "drafting",
  "denial": "den_01JBXG2N5R8W",
  "letter": null,
  "refused_reason": null,
  "created_at": "2026-10-29T16:00:00Z"
}
```

---

## Create a worklist

POST /v1/worklists sends Daybook the accounts you already work; it runs each item through your rules and reports back per item, by API and webhook.

Source: https://daybookhealthcare.com/docs/api-reference/worklists/create

`POST https://api.daybookhealthcare.com/v1/worklists`

### Parameters

- `name` (string, required)
- `items` (object[]): Accounts, one per item. Any columns you have; Daybook maps the standard ones (payer, member, claim, balance).
- `csv_url` (string): Or an HTTPS link to an export from your PM system.
- `rules` (string[]): Rule ids to run on every item.

### Example request body

```json
{
  "name": "AR over 30 days",
  "csv_url": "https://example.com/exports/ar-30.csv?token=...",
  "rules": [
    "rule_01JBXJ1"
  ]
}
```

### Response fields

- `id` (string): Unique id, prefixed `wl_`.
- `status` (string): `processing`, `running` or `done`.
- `item_count` (integer)
- `rules` (string[])

### Example response

```json
{
  "id": "wl_01JBXJ9",
  "object": "worklist",
  "status": "processing",
  "item_count": 0,
  "rules": [
    "rule_01JBXJ1"
  ]
}
```

---

## Create a rule

POST /v1/rules tells Daybook what to do when something happens, such as re-checking a claim with no answer: one rule, applied to every account.

Source: https://daybookhealthcare.com/docs/api-reference/rules/create

`POST https://api.daybookhealthcare.com/v1/rules`

### Parameters

- `name` (string, required)
- `when` (object, required): The trigger: an event type, or a condition on worklist items.
  - `event` (string): An event type, such as `denial.classified`.
  - `condition` (string): A condition, such as `days_since_submission >= 30 and status == "no_response"`.
  - `filter` (object): Narrow it, such as `{"cause": "missing_auth"}`.
- `then` (object, required): The action.
  - `action` (string, required): `claim_status.check`, `call.start`, `portal_task.start`, `appeal.draft` or `notify`.
  - `params` (object): Fields for the action, as in its own endpoint.

### Example request body

```json
{
  "name": "Chase silent claims",
  "when": {
    "condition": "days_since_submission >= 30 and status == \"no_response\""
  },
  "then": {
    "action": "claim_status.check"
  }
}
```

### Response fields

- `id` (string): Unique id, prefixed `rule_`.
- `active` (boolean)

### Example response

```json
{
  "id": "rule_01JBXJ1",
  "object": "rule",
  "name": "Chase silent claims",
  "active": true
}
```

---

## Create a webhook endpoint

POST /v1/webhook-endpoints registers an HTTPS URL to receive Daybook's signed webhook events for the workflows and event types you choose.

Source: https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/create

`POST https://api.daybookhealthcare.com/v1/webhook-endpoints`

### Parameters

- `url` (string, required): HTTPS only.
- `events` (string[], required): Event types, or `["*"]` for all. See [Event types](https://daybookhealthcare.com/docs/webhooks/event-types).
- `description` (string)

### Example request body

```json
{
  "url": "https://example.com/daybook/webhooks",
  "events": [
    "*"
  ]
}
```

### Response fields

- `id` (string): Unique id, prefixed `whe_`.
- `url` (string)
- `events` (string[])
- `secret` (string): Signing secret, prefixed `whsec_`. Returned only on create.
- `status` (string): `enabled` or `disabled`.

### Example response

```json
{
  "id": "whe_01JBXK4R7T2M9P5W3Y6A8C0D1E",
  "object": "webhook_endpoint",
  "url": "https://example.com/daybook/webhooks",
  "events": [
    "*"
  ],
  "secret": "whsec_...",
  "status": "enabled"
}
```

---

## List webhook endpoints

GET /v1/webhook-endpoints lists the HTTPS endpoints you have registered to receive Daybook's signed webhook events, across every workflow you use.

Source: https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/list

`GET https://api.daybookhealthcare.com/v1/webhook-endpoints`

### Response fields

- `data` (object[]): Webhook endpoint objects, without `secret`.

### Example response

```json
{
  "data": [
    {
      "id": "whe_01JBXK4R7T2M9P5W3Y6A8C0D1E",
      "object": "webhook_endpoint",
      "url": "https://example.com/daybook/webhooks",
      "events": [
        "*"
      ],
      "secret": null,
      "status": "enabled"
    }
  ]
}
```

---

## Delete a webhook endpoint

DELETE /v1/webhook-endpoints/{id} removes a webhook endpoint, so Daybook stops sending events to it. Register its replacement first.

Source: https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/delete

`DELETE https://api.daybookhealthcare.com/v1/webhook-endpoints/{id}`

### Parameters

- `id` (string, required, in path)

### Response fields

- `id` (string)
- `deleted` (boolean)

### Example response

```json
{
  "id": "whe_01JBXK4R7T2M9P5W3Y6A8C0D1E",
  "object": "webhook_endpoint",
  "deleted": true
}
```

---

## Send a test event

POST /v1/webhook-endpoints/{id}/test sends one signed webhook.test event to an endpoint now and records the delivery, so you can check your handler.

Source: https://daybookhealthcare.com/docs/api-reference/webhook-endpoints/test

`POST https://api.daybookhealthcare.com/v1/webhook-endpoints/{id}/test`

### Parameters

- `id` (string, required, in path)

### Response fields

- `delivery` (object): The delivery, as it shows in the endpoint's delivery log.
- `delivery.event_id` (string): The event's `id`, `evt_` and a ULID, sent as the `webhook-id` header.
- `delivery.status` (string): `succeeded` when your endpoint answered `2xx` within 10 seconds, otherwise `failed`.
- `delivery.response_status` (integer): Your endpoint's HTTP status, or `null` when it did not answer.

### Example response

```json
{
  "delivery": {
    "id": "whd_01JBXK9C3V5N8Q2R4T6W8Y0A1B",
    "endpoint_id": "whe_01JBXK4R7T2M9P5W3Y6A8C0D1E",
    "event_id": "evt_01JBXK8N3QZ7V2C4D5E6F7G8HJ",
    "event_type": "webhook.test",
    "attempt": 1,
    "status": "succeeded",
    "response_status": 200,
    "duration_ms": 142,
    "created_at": "2026-10-29T14:31:40Z"
  }
}
```