RCM and EHR vendors
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.
Build this with AIA brief with this use case's endpoints, events and rules, ready for your assistant to build it in your stack.
How it works
When a provider is added, submit one enrollment per payer with POST /v1/enrollments.
enrollment.submitted confirms it went in.
enrollment.action_required says what the payer wants, such as a signature, and by when.
enrollment.approved or enrollment.rejected closes it; your onboarding screen shows each payer's state.
Replaces A spreadsheet of enrollments chased payer by payer.
Built on
| Event | Sent when |
|---|---|
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. |
The prompt
Paste it into Claude, Codex, Cursor or ChatGPT. It links the docs pages it needs, so your assistant builds against the real API.
I'm building on the Daybook API (healthcare billing: payer calls, payer portals, 270/271 eligibility, 276/277 claim status, 835 remits, denials and appeals). Help me build this end to end.
Use case: 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.