Getting started

Going live

What a live key needs that a test key does not, what is not available yet, and what to prepare while you build in the sandbox.

Everything you can do today runs in test mode, with a test key and the sandbox. This page says plainly what is not open yet, so you can plan.

Where things stand#

Live mode is switched off. The dashboard offers only test keys: the live option is disabled until agreements are signed.
Live eligibility checks are not available yet. A live key gets 503 ELIGIBILITY_UNAVAILABLE for a check. The live payer network is not connected, and there is no date published for it.
Test mode is complete. Test keys, the sandbox scenarios, events, webhooks and the docs all work, so you can finish and test your integration now.

Live mode opens once agreements are signed. Some of what that involves lives outside the product, and the steps and timing are not published yet:

Agreements. Your organization signs a services agreement with Claim House before it can use live mode. Because live checks carry patient information, it also signs a business associate agreement before any is sent. The terms are not published here.
A connection to the payers, set up upstream. Claim House reaches payers through connections that have to be set up and approved before live traffic can flow. That onboarding is done by Claim House, and it is why live mode cannot simply be switched on.
Enrollment with some payers. Some payers need an enrollment before they answer or accept a transaction. Each payer's enrollment_required fields in the directory tell you which. Enrollment as a product is planned and is not available yet.
Live offices. An office has a mode. A live key uses live offices, with the office's real NPI and tax ID, and cannot use a test office.

Keys start with ch_live_, and a live key sees only live data. Your test keys, checks, events and webhook endpoints stay in test mode.
The scripted member IDs (CH-ACTIVE-FULL and the others) no longer choose anything. A live check goes to the payer with the member's real details, and the payer answers for real.
Checks are billed by the rules in Eligibility. Each check's billing object tells you whether it was charged and why. Prices, the monthly minimum, usage and statements are described in Pricing and usage; live billing starts when your organization goes live.
You will handle real patient information: do not log request or response bodies, keep keys on your server, and never put patient information in an Idempotency-Key or a tenant_reference.
Webhook retries are sent when the delivery worker runs. On the hosted service it runs on a schedule; its timing is not promised, so use the events list and Replay to catch up on anything you missed.

Build and test against the sandbox, using every scenario in Sandbox and scenarios: the answers, the rejections you can fix, and the payer that is down.
Handle every outcome of a check. See Eligibility and Errors, retries and idempotency.
Verify webhook signatures and deduplicate deliveries. See Events and webhooks.
Keep keys and webhook signing secrets in your server's configuration.
Find out which of your payers need enrollment: filter the directory with enrollment_required=true.

The changelog lists what is available now.