Daybook DocsDaybook Docs
Browse

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.

Build this with AIA brief with this workflow's endpoints, events and docs, ready for your assistant to scaffold the integration in your stack.

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.

Step through it

Step 3 of 5: Approval, if it changes something, sends portal_task.approval_required

portal_task.approval_required
{
  "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=..."
    }
  }
}

Journeys in this workflow

Find a missing remitThe payment hit the bank but no 835 came. Pull it from the portal.
Check an appealSee where an appeal stands without signing in.
Send an attachmentUpload what the payer asked for, after a person approves it.
Catch an overpaymentRead overpayment letters before the payer takes the money back.

Use cases

What teams build on this workflow, each with a prompt you can paste into Claude, ChatGPT or Cursor.

APIs powering this workflow

Events you receive

Subscribe to these with a webhook endpoint. Every event is signed; see Verifying signatures.

EventSent when
portal_task.approval_requiredA step would change something in the portal and is waiting on you.
portal_task.completedThe task finished, with its result and evidence.
portal_task.failedThe task could not finish, with the reason.
Example event
{
  "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=..."
    }
  }
}
On this pageAt a glanceWhat this workflow enablesTypical flowJourneys in this workflowUse casesAPIs powering this workflowEvents you receive