A test account can look harmless until its follow operations or deletion requests reach the live environment. Development and production need boundaries that are visible in both code and deployment configuration.
Use different secret references and clear environment names. Where your provider supports separate workspaces or projects, use those documented boundaries for test data as well.
Make the environment observable
A developer should be able to tell which base URL and workspace identity an integration uses without printing a secret. Show safe environment information in internal diagnostics. Keep it out of public screens unless it helps a user make a real decision.
Centralize API configuration. A search client, a webhook worker, and a token-minting route should not each contain their own unrelated fallback address. Avoid falling back to production when a required development setting is missing.
Use controlled fixture users and clearly named test records. A cleanup job should match exact test ownership, not delete every account with a common email domain or a short prefix that real users might share.
Test a mistaken deployment
Start the application with a missing credential, a development credential in production configuration, and a webhook signed for another environment. Each case should fail clearly rather than silently reaching a different service.
Review build-time variables separately from runtime secrets. Public frontend configuration may be copied into the final JavaScript bundle, while a server environment variable can remain private.
Keep an environment checklist in the release runbook: base URL, workspace, secret reference, webhook destination, and a safe health request. The checklist is small, but it prevents a large class of errors that otherwise look like random missing data.