Environments
There are two environments, and they share almost nothing at runtime:
| Sandbox | Production | |
|---|---|---|
| Purpose | Build and test | Real clinics |
| Data | Synthetic dataset | Real patient data |
| Client registration | Separate public client | Separate public client |
client_id |
Sandbox-specific | Production-specific |
| Availability | Self-serve, instant | After security review |
| Redirect URIs | HTTPS, or HTTP on loopback IP literals | HTTPS only |
What does carry over is your configuration as intent: the same developer app, permission schema versions, and URIs are the source for both registrations — the sandbox is where you prove a configuration before the same snapshot goes to security review for production.
Practical consequences
- Configuration is per-environment where it must be. Your local
development redirect URI (
http://127.0.0.1:…) belongs to the sandbox configuration; production carries your deployed HTTPS URIs. - Store credentials per environment. Your app should treat (environment, issuer, client_id) as a unit — never send a sandbox client id to a production issuer.
- Sandbox is the canary. API changes land in the sandbox at least one release cycle before production, so a continuously exercised sandbox integration is your cheapest early-warning system.
- Nothing you do in the sandbox affects production — deploys, scope changes, and revocations are isolated to their environment.