Developer Sandbox

Partners develop against the shared plugin-dev sandbox — a full Dentolize deployment with a deterministic demo clinic, reseeded weekly.

What you get

• A demo-clinic login (web UI) so you can see what clinic staff see.
• Your draft listing pre-created; draft listings are installable on the sandbox without review, so you can iterate on your settings schema live.
• A dtz_test_ token for your installation (test tokens are rejected in production — the environments never share data).
• The seeded demo plugin (demo-appointment-reminders) as a working reference.

Sandbox-only relaxations

• Webhook endpoints may use HTTP and tunnel/local addresses (production enforces public HTTPS + SSRF checks).
• Test-token rate limits are lower (60 weighted points/min) to surface throttling handling early.

Local webhook development

1. Run your service locally; expose it: cloudflared tunnel --url http://localhost:3000 (or ngrok).
2. In the sandbox clinic UI: your plugin → Settings → Connection → add the tunnel URL as a webhook endpoint; copy the signing secret (shown once).
3. Press Send test event for each subscribed type and verify signatures.
4. Exercise real flows (create an appointment in the demo clinic UI) and watch deliveries in the Activity tab — attempts, response codes, and response snippets are all visible there.

Data policy

Sandbox data is synthetic and wiped on reseed. Do not put real patient data into the sandbox; production credentials never work there and vice versa.

Operations (Xolize internal)

The sandbox rides the existing per-branch infrastructure: sandbox dentolize plugin-dev deploy pinned to the platform branch; weekly reseed via the sandbox-ops workflow; yarn workspace @dentolize/server babel-node src/generateServerData/seedDemoPlugin.js upserts the demo listing after reseed.