Step 1 — Understand the lifecycle
Open the X12 Quickstart (/integrations/x12-quickstart). The whole flow is: bill → 837P (your professional claim) → 999 (functional ack, syntax accepted) → 277CA (payer claim acknowledgment, accepted or rejected) → 277 (mid-cycle status) → 835 (electronic remittance with payment). You submit the 837P and the four inbound transactions arrive on their own; Mindbill parses each and emits a webhook so you react to events rather than poll.
Step 2 — Get a token, then POST an 837P
Step one of the quickstart is a one-minute task: generate a read+write API token at /integrations/api-tokens (copy it once — tokens are SHA-256 hashed at rest). Then POST your X12 envelope to /v1/edi/837p — raw EDI or JSON, your choice. Mindbill returns a tracking ID and auto-routes the bill to the configured clearinghouse for that payer, so you never select Carisk, Jopari, or Data Dimensions by hand.
Step 3 — Receive the acks and the ERA
Within roughly 5–30 minutes Mindbill emits the 999 functional ack, then the 277CA claim acknowledgment, then periodic 277 status updates, and finally the 835 ERA carrying the payment and its CAS adjustment codes. The copy-paste cURL and Node samples on the page show both the submit call and the webhook handler, so you can wire the listen side without reverse-engineering the payload shapes. The reference panels link the 13 REST endpoints, the 10 webhook event types, and the X12 segment/CAS/STC reference.
Step 4 — Validate in the sandbox first
Before you submit to production, use the EDI Sandbox (/integrations/edi-sandbox): paste an X12 envelope or generate one from an existing bill, and it validates the segments without submitting anything to a clearinghouse. This is the recommended starting point for first-time integrators — you confirm your 837P parses cleanly and your handler reacts correctly to each ack, with zero risk of sending a malformed bill to a real payer.
