835 to posting in your PM system

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.