How a portal task runs
Lookups run on their own. Anything that changes something in a portal is held for a person first.
Payer portals in the docs →- Step 1Start the task
- One request names the payer, the task and the claim or provider it is about: a remit lookup, a claim lookup, an appeal status, an attachment upload or an overpayment lookup.
- Step 2Daybook signs in
- It uses the provider's portal account, handles the two-factor code and picks the portal that answers the task for that payer.
- Step 3Approval, if it changes something
- A lookup runs on its own. A step that would change something in the portal stops and waits for a named person on your team, with a screenshot of exactly what will be sent.
- Step 4You approve
- From your own system or from the Daybook app. Nothing goes through until you do.
- Step 5The result
- What Daybook read back comes to your system as data, with every page it captured along the way kept as evidence. A run that cannot finish stops with a plain reason and a screenshot.
For medical billers
Some answers exist only in a portal. Daybook pulls the remit or the claim detail when the 835 never arrived, checks where an appeal stands and reads overpayment letters before the payer takes the money back. Your billers approve anything that changes a portal, and nothing is submitted without them.
- Remit lookup, claim lookup, appeal status, attachment upload and overpayment lookup
- A remit or claim detail pulled from the portal when the 835 never came
- A failed sign-in halts the agent before the portal locks the account
- Every page captured as evidence, and a plain reason when a run cannot finish
More for medical billers: the billers page.
For dental billers
Where a dental payer answers only in its portal, Daybook signs in, handles the two-factor code, runs the lookup and hands your biller the result as data. The human steps are handed off cleanly. A change waits for a named person on your team, and a run that stops says why.
- Portal logins and two-factor codes handled
- A change held for a named person on your team, with a screenshot of what will be sent
- A remit or claim detail pulled from the portal when the 835 never arrived
- A run that cannot finish stops with a plain reason and a screenshot
More for dental billers: the dental page.
Starts from your knowledge base
Your billing company's own rules, appeal workflows, payer quirks and call scripts are what Daybook runs. You send the documents, Daybook imports them as payer guides, shows you what it produces, and you adjust it together on a call. Each solution runs on its own, so you start with one and add the next.
For portal work that is your portal guides: which portal answers which payer, the steps your biller takes in each, and who approves a change.
- Your portal guides, one per payer and task
- Who on your team approves a change before it is sent
- What counts as done, and what stops a run
Where it shows up
- A signed webhook
- The result and its evidence, and the approval request before any change
- The Daybook dashboard
- The run, its screenshots and the approval waiting for a named person
- The claim in your PM or EHR
- What the portal showed, as fields
One portal action, one request
Signing in, the two-factor code and the task run as one API call. A change waits for your approval, and the result comes back as a signed webhook with its evidence.
Read payer portals in the docs →Frequently asked questions
What billing teams ask us about payer portals, and our answers.
Does anything go into a portal without our approval?
No. Lookups run on their own. Any step that changes something in a portal stops and waits for a named person on your team, with a screenshot of exactly what will be sent, and goes through only after that approval.
What happens when a sign-in fails or the portal asks for a code?
Daybook handles the two-factor code as part of the sign-in. A run that cannot finish stops with a plain reason, such as a pending code, a portal error or a lockout, and a screenshot. A failed sign-in halts the agent before the portal locks the account.
Which portal tasks can Daybook run?
Remit lookup, claim lookup, appeal status, attachment upload and overpayment lookup. Pull a remit or claim detail when the 835 never arrived, check where an appeal stands without your biller signing in, upload what the payer asked for once a person approves it, and read overpayment letters before the payer takes the money back.
What does our team get back?
The result comes back as fields in a signed webhook, so nobody retypes a screen, and every page the agent captured along the way is kept as evidence.
Where does the automation run, and is it covered by a BAA?
The browser automation runs on Cloudflare Browser Run. Cloudflare and Fly.io have signed BAAs with Daybook, and Daybook signs a BAA with every client before any PHI moves.