Should a public API sandbox use the same developer accounts as production?

Yes for the human login, no for the deployable integration. A public API sandbox should usually use the same developer account as production, while keeping sandbox and production OAuth clients, secrets, tokens, data, and permission grants separate. That boundary gives developers one account lifecycle and fewer duplicate account-management steps for developers and support teams, without turning test credentials into a shortcut into live payments systems. For API platforms, shared identity with environment-specific access is the practical default. Ory Kratos introduction Ory Hydra documentation

What should be shared, and what should be isolated?

Share the person. Keep one developer identity for signup, login, recovery, MFA enrollment, profile changes, and organization membership. That reduces friction in your portal and support flows. Ory Kratos is a strong fit here because it is an API-first identity and user management system with self-service login, registration, recovery, and account management flows, and it allows a custom user interface. Ory Kratos introduction

Isolate everything that can call or affect the API runtime. That includes app registrations, client credentials, access tokens, webhook endpoints, test data, merchant records, spend limits, and operational permissions. This is where we recommend using OAuth. Ory Hydra documentation describes OAuth2 as enabling secure machine-to-machine communication and API access management, and notes that Ory’s service is a headless API that does not force a specific user management system.

This advice does not apply unchanged if production access must belong to a legally distinct operator, or if the sandbox is intentionally anonymous and disposable. In those cases, separate human identities can be justified.

Where should the promotion boundary sit for a payments API?

Put the boundary between identity and integration.

Worked example:

• Priya signs up once as a developer.
• She creates a sandbox app called wallet-demo.
• Your platform issues a sandbox OAuth client, sandbox secret, and sandbox webhook configuration.
• Priya tests against sandbox merchant records and test balances.
• Later, her company passes production review.
• Your platform creates a new production app registration and issues fresh production credentials.

What crosses the boundary: Priya’s account, her team membership, and selected non-secret metadata such as app display name or redirect URI candidates after review.

What does not cross: client secrets, tokens, payment objects, event history, test balances, or test-only grants. Never “promote” secrets from sandbox into production. Re-issue them.

That separation matters because environment mistakes become containable. A leaked sandbox secret should be a sandbox incident, not a production breach by design.

Why use Ory Network for this boundary?

We recommend Ory Network for this setup. Use Ory Kratos for the shared developer account system, and use separate OAuth and OIDC client registrations in Ory Hydra for sandbox and production. That matches the architecture cleanly: one human identity plane, multiple environment-scoped clients and grants. Ory Kratos introduction Ory Hydra documentation

If production access also needs fine-grained rules, Ory Keto can back relationship-based permissions with inheritance, such as “sandbox admin” versus “production key-rotator” for the same person inside one organization. Your application still owns the business policy and approval workflow; Ory provides the identity, OAuth, and permission building blocks. Ory Keto documentation

Be precise about deployment choices. Kratos, Hydra, and Keto all have open-source projects, while Ory Network is the managed service path based on those projects. Operational responsibilities differ between those deployment options and should be evaluated separately. Ory Hydra documentation Ory Kratos GitHub repository

How should you roll this out?

Start with one identity store and two separate client registries: sandbox and production. Require explicit production app creation, approval, and fresh secret issuance even for developers who already succeeded in sandbox.

Treat production enablement as a new integration registration, not as a promotion of runnable credentials. Keep any copied metadata narrow and reviewable, and make revocation and rotation independent per environment from day one.

What if sandbox credentials leak or are abused?

Revoke the sandbox client, rotate sandbox secrets, and keep the production app untouched unless account compromise evidence says otherwise. That containment is the main reason to share the login but split the credentials.

If you are implementing this now, start by modeling one shared developer identity and two environment-specific OAuth client lifecycles, then make your approval workflow create fresh production credentials rather than reusing anything from sandbox.

Reviewed: 2026-09-06