API Platform & Lifecycle · Developer Experience
Onboarding: Keys, Sandboxes and Test Data
Get developers from signup to working integration quickly and safely.
Self-service onboarding: a developer portal for signup, API keys with scopes (separate test/live keys, e.g. sk_test_…/sk_live_…), a sandbox environment with realistic test data and magic values (test cards that trigger declines, test webhooks you can resend), request logs per key, and a webhook testing tool. Make the test environment behave like production (same validation, rate limits relaxed but present).
Onboarding toolkit
| Element | Purpose | Example |
|---|---|---|
| Test vs live keys | Prevent accidental real actions | sk_test_ / sk_live_ prefixes |
| Magic test values | Trigger edge cases on demand | Card 4000…0002 → declined |
| Request logs per key | Self-service debugging | Dashboard of recent calls + errors |
| Webhook tester | Validate receivers | Resend events, inspect signatures |
| CLI tooling | Local webhook forwarding | stripe listen --forward-to localhost |
# Key prefixes make leaks detectable by secret scanners
sk_test_51Nq... # test mode secret key
sk_live_51Nq... # live mode secret key (register prefix with GitHub secret scanning)
Common pitfalls
- Sandboxes that behave differently from production.
- No way to test error paths.
- Keys without prefixes that scanners can't detect when leaked.
Key points
- Test/live separation
- Magic values for edge cases
- Self-service logs and webhook tooling
Further reading: Stripe: Testing
Practice questions
Why add recognizable prefixes to API keys?
Answer
They make the key type/environment obvious and allow secret-scanning services (e.g., GitHub) to detect leaked keys automatically and notify you.
What are 'magic values' in a sandbox?
Answer
Special test inputs that deterministically trigger specific outcomes (declines, timeouts, fraud flags) so integrators can test error handling.
Open in the app to mark lessons complete, take notes and track your progress.