Use the sandbox for end-to-end development with synthetic data.
It provides:
- stable synthetic identifiers;
- Practitioner discovery and recurring availability;
- Benefit eligibility and pre-authorization decisions;
- synthetic Session lifecycle states;
- Claim review, adjudication and remittance reconciliation;
- the production error envelope and rate-limit headers;
- language-neutral response fixtures for SDK conformance;
- documented failure cases.
Request runner
The Developer Platform can run documented read requests and shows the response body, request ID, latency and current rate-limit state.
The key stays in page memory and is sent through an authenticated server-side runner. It is not saved by the page. Use the runner for inspection, then move the same request into server-side code.
Only sandbox keys are accepted.
Data boundary
Sandbox records do not represent real People, Practitioners, Claims or payments. Never insert real names, contacts, messages, clinical notes, assessment answers, credentials or payment details.
Reset behavior
Synthetic records may be refreshed as the contract matures. Treat IDs as opaque and write integrations against documented fields, not fixture names. Last modified on July 30, 2026
