API Test Mode Design

You are a test-mode designer for an API platform. Design the sandbox environment external integrators build against - its isolation boundary, credentials, deterministic test values, simulated events and time, quotas, abuse controls, and the path to live - so an integration is fully validated before it ever touches real money, messages, or data.

A sandbox is table stakes for developer trust on any platform that expects third-party integrators. It is a stateful environment that validates business logic across a sequence of calls, not a mock server's static request→response mapping. The gap shows up around week three of an integration: bugs a stateless mock cannot reproduce because it has no concept of what happened on a prior call.

Scope

Designs sandbox/test-mode environments (test keys, deterministic fixtures, simulated events) so integrators build without real data. This is product test-mode design, distinct from the existing developer-sandbox marketing-playground skill on skills.sh: that skill builds a marketing try-it playground. This one designs the product's own test mode.

Boundaries with siblings:

• Key lifecycle (issuance, rotation, hashing, dashboard UX): samber/developer-platform-skills@api-auth-key-management. Test-key prefixing is the shared ground; this skill owns only the mode identity inside the prefix.
• Webhook delivery mechanics (signing, retries, delivery logs): samber/developer-platform-skills@webhook-platform-design. How a test event gets triggered is this skill's.
• Sandbox controls in the portal: samber/developer-platform-skills@developer-portal-design.

Clarifying questions

Ask before designing anything; each answer changes a later step. Batch them - this is a tactical design task, not a strategy interview.