Sandbox environment

A separate deployment of the exact same code as production, with an isolated database, seeded demo data, and a nightly reset. Use it for the Try-It panel in the docs, integration testing, and anything you would not want touching real agent wallets or real audit chains.


Base URL	`https://sandbox.api.insurelink.vitalplatforms.com`
Environment header	Every response carries `X-InsureLink-Environment: sandbox` — check it to be certain you are not talking to production
Reset schedule	03:00 UTC nightly (systemd timer) — the database is dropped, migrations reapplied, and the seed re-run
Data isolation	Its own Postgres database (`insurelink_sandbox`) and Redis DB — nothing shared with production
Rate limits	Same as production (per-endpoint throttles + global 120/min/IP)

What is pre-seeded

Every reset leaves the sandbox in a state where a first API call succeeds without any admin setup.

The seeded super-admin:

email:    admin@insurelink.local
password: ChangeMe!Insur3Link2026

curl -sSX POST https://sandbox.api.insurelink.vitalplatforms.com/api/v1/auth/login \
  -H 'content-type: application/json' \
  -d '{"email":"admin@insurelink.local","password":"ChangeMe!Insur3Link2026"}'

Save data.accessToken for the rest of this page.

Demo agent

A KYC-verified licensed agent is created on every reset. The UUID changes on every reset, but the code and email are stable, so the docs reference them by those:

Field	Value
`code`	`AGT-DEMO-SANDBOX`
`email`	`demo.agent@sandbox.insurelink.local`
`insurelinkAgencyNumber`	`ZFA-DEMO-00001`
`iraRegistrationNumber`	`IRA/IA/0001/2026`
`status`	`active`
`kycStatus`	`verified`

Look up the current id when you need it:

curl -sS "https://sandbox.api.insurelink.vitalplatforms.com/api/v1/agents?search=demo" \
  -H "authorization: Bearer $ACCESS" \
  | jq -r '.data[] | select(.code=="AGT-DEMO-SANDBOX") | .id'

Active insurers + products

Three insurers and one product per insurer are activated so referrals can be created. All other insurers/products remain inactive to keep the demo focused. List the active set with:

curl -sS "https://sandbox.api.insurelink.vitalplatforms.com/api/v1/insurer-products?pageSize=10" \
  -H "authorization: Bearer $ACCESS" \
  | jq '.data | map(select(.isActive==true)) | .[] | {id, name}'

Reference data from the base seed

Everything the production seed produces is also in sandbox: 243 permissions, 8 roles, 27 Uganda insurers, 15 default policies, 4 default investment products, 3 default deductions, and the ZFA fee / URA WHT / IIU membership schedule. Only the activation state differs from production — sandbox flips the demo subset on.

End-to-end example: create a referral

ACCESS=$(curl -sSX POST https://sandbox.api.insurelink.vitalplatforms.com/api/v1/auth/login \
  -H 'content-type: application/json' \
  -d '{"email":"admin@insurelink.local","password":"ChangeMe!Insur3Link2026"}' \
  | jq -r '.data.accessToken')

AGENT_ID=$(curl -sS "https://sandbox.api.insurelink.vitalplatforms.com/api/v1/agents?search=demo" \
  -H "authorization: Bearer $ACCESS" \
  | jq -r '.data[] | select(.code=="AGT-DEMO-SANDBOX") | .id')

PRODUCT_ID=$(curl -sS "https://sandbox.api.insurelink.vitalplatforms.com/api/v1/insurer-products?pageSize=10" \
  -H "authorization: Bearer $ACCESS" \
  | jq -r '[.data[] | select(.isActive==true)][0].id')

curl -sSX POST "https://sandbox.api.insurelink.vitalplatforms.com/api/v1/referrals" \
  -H "authorization: Bearer $ACCESS" \
  -H 'content-type: application/json' \
  -H 'idempotency-key: my-first-sandbox-referral' \
  -d "{
    \"agentId\": \"$AGENT_ID\",
    \"insurerProductId\": \"$PRODUCT_ID\",
    \"clientFirstName\": \"Grace\",
    \"clientLastName\": \"Hopper\",
    \"clientEmail\": \"grace@example.ug\",
    \"clientPhone\": \"+256701555002\",
    \"requestedCoverage\": 5000000,
    \"currency\": \"UGX\"
  }"

Returns a data.referenceNumber like REF-26-XXXXXXXXX and status: "draft". From there you can walk the referral through the 9-state workflow (submit → send-to-insurer → quotation → premium confirm → policy issued), or exercise the wallet, commission, or claim endpoints.

Try-It panel

Every endpoint in the API Reference has a Try-It panel. The server dropdown defaults to Sandbox; you have to explicitly pick Production before you can hit real data. The docs site itself never stores your access token — it lives only in your browser tab.

What sandbox will not do

Send SMS / email: notification templates render but the transport is stubbed. Look at notification.dispatched audit events, not your inbox.
Call live insurer webhooks: outbound webhooks target a stub base URL and are marked delivered without actually leaving the box.
Charge real payment processors: POST /payment-webhooks/{provider} still requires a valid HMAC signature; a helper endpoint mints valid demo signatures if you need one.
Persist your changes past 03:00 UTC: everything you create is wiped on the nightly reset. If you need state to persist, mount your own scenario in the seed and re-deploy.

Reset log

You can watch the last reset from any workstation:

curl -sS https://sandbox.api.insurelink.vitalplatforms.com/api/v1/system/info \
  -H "authorization: Bearer $ACCESS" \
  | jq '{env: .data.env, releasedAt: .data.releasedAt}'

If env reads anything other than staging, you are not on sandbox — do not proceed with destructive testing.

What is pre-seeded​

Login​

Demo agent​

Active insurers + products​

Reference data from the base seed​

End-to-end example: create a referral​

Try-It panel​

What sandbox will not do​

Reset log​