DEV sandboxes & test keys

Get a sandbox

Request a developer sandbox from Developers & Integrations. A founder provisions the DEV school; requesting it does not immediately create a school or copy live families. Sandbox access is tied to that marked owner identity.

Create the key within that sandbox. Test keys start with sk_test_; dedicated connector keys also carry their app kind and selected areas/locations. Use https://swum-53cd2-api.web.app/v1 for sandbox REST calls. Production refuses test keys, and a key from a different or unmarked owner cannot use the sandbox identity.

For OAuth/MCP, use the exact issuer and resource origin supplied for the DEV deployment. A REST key, including a test key, cannot authenticate /mcp; agents use OAuth tokens.

What to verify

• There is no automatic copy of a live school, account linking by email or automatic signup invitation from API family/swimmer creation.
• Use synthetic families and controlled recipients. Verify owner/location isolation and private/medical-field exclusion.
• Test create/update, duplicate contacts, stale edits, notes, enrollment request versus free-occurrence mode, and revoked/expired access.
• Replay POST, PATCH and DELETE with the same operation key and confirm the same result/proposal. For MCP use idempotency_key.
• Approve and decline Ask Me First cards. Distinguish owner approval from family enrollment confirmation or meet payment.
• Check the full webhook lifecycle, raw-byte signatures and retry behavior. Private connectors must also be validated inside the intended partner platform.
• DEV does not automatically suppress every notification. Keep school communication controls and controlled-recipient checks in place.

Going live

Production access, DNS, the intended endpoint origin, owner/plan rollout and per-feature settings are separate release steps. Create production keys only after the intended school is enabled. Keep test ids, contacts and secrets out of production workflows, and verify the actual hosted flow before inviting users.