Skip to main content
This guide is for workers’ compensation payers and TPAs. You submit an occupational-injury referral with claim identifiers, track it through the report, and pull payments once the referral is no longer pending or canceled. Before using this guide you need a sandbox and an access token. Request keys from Get API keys. How to send Authorization is in Authentication. Use synthetic data only on the initial sandbox. Listing imaging centers, searching or creating practices or law firms, and submitting an order-form-only referral may be off until Scan enables them for your account. Register the patient first with Submit a medical referral (or nest referral.patient on the create call below). Safety answers and preferred times are optional add-ons: Submit medical questions and Submit preferred times. The combined intake is Submit for scheduling. POST /api/v2/referrals selects workers’ compensation when order_type is workers_comp. The legacy payment_type field can be omitted and defaults to pi; it does not select the line of business. The create body is the workers’ compensation referral shape in Creates a referral. Look up exact procedure IDs with CPT codes and diagnosis IDs with ICD-10 codes.

Send the workers’ compensation referral

POST /api/v2/referrals
What you get back. The referral, including id. On GET /api/v2/referrals/{referral_id} expect line_of_business: workers_comp, plus payor, insurance_number, and wc_number when those identifiers are on file. The field names intentionally differ by direction: send payer and wcb_number; read payor and wc_number. To correct claim, payer, or adjuster details after create, use Updates a referral.

Status changes

Every status, what it means, and how changes reach you are on Track referral status. One thing is specific to workers’ compensation: a visit sits in pending_auth while we wait on claim authorization, which can hold up booking for as long as the payer takes. Do not poll for the internal steps in between — wait for the next webhook or take a snapshot when you need one.

Pull payments

Payments are logged against the referral, not the visit. They can arrive months after invoice ready, so treat the list as something you keep pulling rather than a one-shot after the report. Do not call this while the referral’s top-level status is pending or canceled. Once it leaves those two — typically invoice_ready, then invoice_sent, closed, or another accounts-receivable value — keep listing payments. An empty referral_payments array is expected until Scan logs one; do not treat the first empty response as final. Visit invoice_ready only means reporting is finished for that visit. It is not a signal that a payment exists. See Track referral status. This capability is off until Scan enables payment read for your account. Without it the endpoint returns 403. GET /api/v2/referrals/{referral_id}/payments
Results are newest first and paginated with page and per_page (default 20). Procedure description is the portal study string. date and check_number can be null on older payments. Full schema: Lists referral payments.