Sign in

Build

Sandbox first, live when ready

Develop with synthetic data and the same API surface used in production. Live claims remain disabled until your organization completes security and billing setup.

Create a sandbox key

Open the developer console, create a sandbox organization, and copy the key when it is shown. Sandbox organizations accept synthetic data only and never route a claim to a payer.

Test your integration

  1. Create a synthetic bill with a final report, save its bill ID, and confirm it appears in All Bills.
  2. Use the sandbox simulation endpoint to exercise acceptance, rejection, and payer processing. Check status, EORs, attachments, and available actions.
  3. Test a corrected bill, second review, and payment posting through the lifecycle workflow.
  4. Verify that unauthenticated users, users from another customer, and non-admin settings users are denied. Check session expiry and refresh.
  5. For components, test empty and error states, narrow screens, and scrolling inside your app. Bills waiting on payers must remain visible in All Bills.
  6. Verify webhook signatures, duplicate events, and out-of-order delivery. Reconcile current bill state; browser callbacks alone are not a durable record.

Add notification settings to your existing settings page with NotificationSettings and an authenticated host-server adapter, or use your own settings UI. Notifications are off by default. Once activated for your integration, MindBill can notify explicitly consenting users for assigned bills or an authorized whole practice, without console accounts. Signed webhooks support custom messages or delivery. Contact suggestions and rendering a component never enroll recipients automatically.

Account controls

CapabilityServer permission
Read account, keys, and usageaccount:read
Accept the BAA and update security settingsaccount:write
Create and revoke API keyskeys:write
Read organizationsorgs:read
Create organizations and manage accessorgs:write
Update reusable source profilessettings:write

Browser access uses the separate browser permission set, assigned from your application’s roles. A submitted bill has no edit permission because its snapshot and payer packet are immutable.

Go live

Live routing requires an approved organization, a current BAA, payment setup, and a verified webhook endpoint. The API and components do not change when live access is enabled; rotate to the live key and keep your origin and role policy unchanged.

Configure browser-session permissions →