Should I use one API key per environment, or share keys across environments?

Every Valid Email Checker account that runs the API in more than one environment should hold separate keys per environment. The cost is nothing — keys are free to create up to the per-account cap — and the benefits compound across security, debugging, and operations. Sharing one key across production, staging, and laptops is a foot-gun waiting to fire.

Why one key per environment

• Revocation is contained. If a developer accidentally commits a key to a public repo, you revoke just that one key. The rest of your environments keep running. Sharing a key means a single leak forces every system that uses it to rotate at the same time.
• Usage is attributable. Credits History shows the key prefix on every API charge. Per-environment keys let you tell at a glance whether the spike came from production or from a runaway staging script. Shared keys lump everything together.
• Rate limits don't cross-pollute. API rate limits apply per key. A misbehaving staging deploy that hits the rate limit doesn't degrade your production traffic — staging gets the 429 errors, production keeps running.
• Audit trail is clean. When someone leaves the team, you revoke the keys they had access to without touching the production key the company depends on.

Recommended key set for most teams

A typical Valid Email Checker production deployment has three or four keys:

• Production. Lives only on production servers, stored in your secrets manager. Never in source code, never in a local .env, never in a developer laptop.
• Staging. Lives on the staging environment. Used for end-to-end tests, pre-deploy verification, internal demos. Lower-volume, easier to rotate.
• Development. Each developer holds a personal key for local testing. Stored in their local environment, not shared. The blast radius is one developer.
• Ad-hoc scripts. A separate key for one-off data tasks (cleaning a legacy list, importing from a deprecated system). Created, used, and revoked the same week.

You can hold up to the per-account cap of active keys — see the max number of active API keys for the exact limit. Most teams use 4 to 8 active keys at any time.

Naming keys for legibility

When you create a key in the dashboard, give it a name that tells you what it does. production-signup-form, staging-ci-tests, dev-jane-laptop, migration-q3-cleanup. Future-you will be grateful. Generic names like "main" or "test" are useless after a few months.

Rotation cadence

Rotate production keys annually as a habit, and immediately if there's any reason to suspect a leak (a former employee, a security incident at a vendor, an unexpected usage spike). The dashboard's revoke action invalidates the key without deleting it, so the historical Credits History entries keep their attribution. See the difference between revoking and deleting an API key for which to pick when.