How to Manage Multiple Mockupanda API Keys Across Dev, Staging, and Production Environments Without Leaking Credentials

If you have ever found an API key committed to a public GitHub repository, you already know how quickly that can spiral into a problem. Credentials leak in predictable ways: a developer pastes a key into a .env file and commits it, a staging config ends up in the wrong place, or a team member leaves and nobody rotates their keys. For a mockup generation workflow built on the Mockupanda API, a leaked key means someone else could burn through your credit wallet generating mockups on your dime.

This guide covers every step of managing Mockupanda API keys across a real multi-environment setup, from creating separate keys for each stage of your pipeline to storing them safely, rotating them on schedule, and responding quickly when something goes wrong.

Why One API Key for Everything Is a Bad Idea

The blast radius problem

When you use a single API key everywhere, a compromise in any one environment compromises everything. A leaked dev key is a nuisance; a leaked production key can drain your wallet and disrupt live listings. Separating keys by environment contains the blast radius. If your staging key gets exposed, you revoke it, generate a new one, and your production integration keeps running without a gap.

The same logic applies when a team member leaves. If that person had access to a shared key used in development, staging, and production, you now have to rotate across all three simultaneously, update every service that depends on it, and hope nothing breaks in the process. With per-environment keys, you revoke only what that person touched.

Rate limits apply per key, not per account

There is a practical performance reason to use multiple keys as well. The Mockupanda API enforces rate limits of 100 requests per minute and 10,000 requests per day, and those limits apply per API key, not per account. That means using multiple keys across your services genuinely increases your total available throughput. If you are running a high-volume batch mockup generation workflow, having separate keys for separate services means each service gets its own full rate limit budget.

Auditability and the "Last Used" timestamp

Every key in your dashboard shows a Name, its status (Active or Revoked), when it was created, and when it was last used. If you give each key a descriptive name like "Production Server" or "Dev Environment", you can glance at the Last Used timestamp and immediately tell whether a service is still active or whether a key has gone stale. With a single shared key, you lose all of that visibility.

Takeaway: Create a separate key for every environment before you write your first API call. It costs nothing, adds no complexity to key creation, and gives you much finer control if anything goes wrong.

Creating and Naming Keys in the Dashboard

The creation process

All key management happens inside your Mockupanda dashboard. To create a new key, log in, navigate to Dashboard, then API Keys, and click "Create API Key". You will be prompted to give the key a name before the key itself is generated.

This naming step matters more than it looks. A vague name like "Key 1" tells you nothing three months from now when you are trying to figure out which key to revoke. A descriptive name like "Production Server", "Staging Integration", or "Dev Environment" makes the purpose immediately obvious. If you are building a platform with per-service or per-client keys, names like "Image Resize Service" or "Client A Mockup Pipeline" keep things readable as the list grows.

Once the key is generated, copy it immediately. The key will not be shown again after you close that screen. Each key starts with the prefix mpa_, which is a useful signal for detection tools and secret scanners.

There is no limit on the number of active keys per account, so you can create keys as granularly as your architecture requires, including temporary keys for testing or one-off demos that you plan to revoke as soon as the task is done.

Naming conventions that scale

A simple naming convention saves a lot of confusion as your setup grows. Consider a format that includes the environment and the service: prod-storefront, staging-webhook-handler, dev-local-testing. That way, at a glance from the API Keys list, you can see exactly which key belongs where. If you are managing keys for multiple clients on a platform, adding a client identifier keeps things unambiguous: prod-client-acme, staging-client-acme.

Document these conventions somewhere your team can find them, even if it is just a short section in your internal runbook. The person handling a 2am incident should not need to guess.

Takeaway: Create keys with environment and service context baked into the name. Copy the key immediately on creation, name it clearly, and document your naming convention so the whole team follows the same pattern.

Storing Keys Safely: Environment Variables and What to Avoid

Never commit a key to version control

The single most common way API keys leak is through version control. A developer adds a .env file with a real key to test something, forgets to add .env to .gitignore, and pushes to GitHub. Even if the commit is later removed, bots scan public repositories continuously and can capture a key within minutes of it appearing.

The rule is simple: never commit API keys to version control, never expose them in client-side code, and never share them publicly in places like GitHub issues or Stack Overflow answers.

Using environment variables correctly

The right place for your Mockupanda API key is an environment variable. For local development, store it in a .env file and make sure .env is listed in your .gitignore. The variable name in that file should be clear and consistent across environments:

MOCKUPANDA_API_KEY=mpa_abcd1234efgh5678ijkl9012mnop3456

In your application code, read the key from the environment rather than hardcoding it. For example, in Node.js that is process.env.MOCKUPANDA_API_KEY, in Python it is os.environ.get('MOCKUPANDA_API_KEY'), and in a shell script it is $MOCKUPANDA_API_KEY. Every language has an idiomatic way to read environment variables; use it.

For staging and production environments, the approach depends on your infrastructure. Cloud platforms like AWS, GCP, and Azure all offer secrets management services where you store the key once and inject it into the runtime environment securely. CI/CD tools like GitHub Actions, GitLab CI, and CircleCI have secrets stores that work the same way. The key point is that the actual key value never appears in your repository or in any file that gets committed.

What the Authorization header looks like in practice

When you make a request to the Mockupanda API, you include your key as a Bearer token in the Authorization header:

Authorization: Bearer mpa_abcd1234efgh5678ijkl9012mnop3456

The Bearer prefix is required. If you omit the Authorization header entirely, the API returns a 401 Unauthorized with the code MISSING_API_KEY. If the key is incorrect or has been revoked, you get INVALID_API_KEY. Those two error codes are worth logging explicitly in your error handling so you know immediately whether a failure is a credential problem or something else.

Takeaway: Store every key in an environment variable and read it at runtime. Add .env to .gitignore before you create the file. Use your platform's secrets manager for staging and production so the key never touches your repository.

Rotating Keys on a Schedule and After Security Events

The 90-day rotation rule

Regular rotation limits how long a compromised key remains useful even if you never discover the compromise. A good baseline is to rotate keys every 90 days. That schedule also creates natural checkpoints to review which keys are still in use and clean up any that have gone stale.

Beyond the calendar, there are specific events that should trigger an immediate rotation regardless of schedule: a team member with access to a key leaves the organization, you decommission a service that used the key, or you have any reason to suspect the key may have been exposed.

How to rotate a key without downtime

The risk with rotation is the gap between revoking the old key and deploying the new one, during which your service gets INVALID_API_KEY errors. The way to avoid that gap is to generate the new key first, deploy the new value to your environment, verify the new key is working, and only then revoke the old one.

In practice that looks like this: go to Dashboard, then API Keys, create a new key with the same descriptive name plus a version suffix if that helps you track it, copy the new key, update your environment variable or secrets manager entry, deploy, confirm your service is making successful requests, then go back to the dashboard and revoke the old key. The old key remains active until you explicitly revoke it, so there is no forced downtime.

Revoking a compromised key immediately

If you suspect a key has been leaked, the response needs to be fast. Go to Dashboard, then API Keys, find the compromised key, and click "Revoke" next to it. Requests made with a revoked key are rejected with INVALID_API_KEY. Then generate a new key, update your application, and deploy. Revoked keys cannot be restored, so you will always need to generate a fresh one.

After revoking, check your wallet transaction history in Dashboard, then Billing to see if there is any unexpected usage you do not recognize. The transaction log shows usage charges with the template or batch that was generated, so unusual entries stand out. If you are tracking costs programmatically, keep in mind that the wallet balance endpoint requires a dashboard session rather than an API key, so automated balance polling is not available through the API alone.

Takeaway: Put key rotation on a 90-day calendar reminder. Build your rotation procedure into your team's runbook so anyone can execute it under pressure. When a key is compromised, revoke first and investigate second.

Structuring Keys Across a Multi-Service Architecture

Per-service keys and what they give you

If your integration involves more than one service touching the Mockupanda API, giving each service its own key pays off quickly. Consider a setup where one service handles artwork uploads and mockup generation, another handles multi-frame template requests, and a third handles rendering for a specific client segment. With separate keys, the Last Used timestamp tells you exactly which service is active. If the multi-frame service goes quiet unexpectedly, you see it without sifting through combined logs.

Separate keys also mean that revoking access for one service does not disrupt the others. If you need to take the multi-frame service offline for maintenance, its key can be revoked or simply left inactive while everything else keeps running.

Per-environment isolation in practice

The standard three-environment setup (development, staging, production) maps cleanly to three keys. Your local development key is used only on developer machines. The staging key is used only in your pre-production environment. The production key is used only in your live application. Each key's Last Used field reflects only real traffic from that environment, which makes anomaly detection much simpler.

One additional category worth considering is temporary keys for testing or demos. If you are building a proof of concept, running a one-time data migration, or setting up a demo environment for a client, create a dedicated key for that purpose and plan to revoke it as soon as the task is finished. That way, temporary access does not accidentally become permanent access.

Using Sets and batch mode responsibly per environment

If your production integration uses Sets to render full template collections with a single request, your staging environment should use a separate set configured for smaller template counts, so you are not consuming production-level credits during testing. Because each key has its own rate limit budget of 100 requests per minute and 10,000 per day, keeping environments on separate keys also means a runaway test loop in staging cannot eat into production's rate limit headroom.

Takeaway: Assign one key per service and one key per environment. Document which key is used where. Revoke temporary keys as soon as the task that required them is done, and treat that cleanup step as part of the task definition, not an afterthought.

Handling Errors Related to Authentication in Your Code

Detecting and responding to credential errors

Your application should treat INVALID_API_KEY and MISSING_API_KEY errors differently from transient errors like 429 Too Many Requests. A 401 with either of those codes is a signal that something structural is wrong: the key was revoked, the environment variable was not injected correctly, or the wrong key is configured for that environment. Retrying the request automatically will not fix it.

A good pattern is to log the full error code on 401 responses to a monitored log channel and alert your team immediately rather than silently failing or retrying. If your production service suddenly starts returning INVALID_API_KEY, you want to know within minutes, not hours.

The INSUFFICIENT_CREDITS response

A 402 Payment Required response with the code INSUFFICIENT_CREDITS is a separate class of error from authentication failures, but it is worth handling explicitly. The response body includes required_cents and balance_cents so you can log exactly how close to empty the wallet was. Because there is no programmatic way to top up the wallet automatically (auto-recharge is not currently supported), an INSUFFICIENT_CREDITS error means someone needs to log into the dashboard and add funds. Building an alert for this response code, rather than letting it appear as a generic failure in your logs, saves real time.

Testing error handling in dev without spending credits

Your development environment is the right place to simulate error conditions. You can test INVALID_API_KEY handling by temporarily using a malformed key in your dev environment. Because your dev key is separate from production, doing this carries no risk to your live pipeline. Failed requests cost zero credits, so testing error paths in dev is free in both the credential and billing sense.

Takeaway: Write explicit handlers for INVALID_API_KEY, MISSING_API_KEY, and INSUFFICIENT_CREDITS. Log the full error code rather than a generic message. Alert on 401 responses in production so credential problems surface immediately instead of hiding in noise.

A Practical Key Management Checklist

Pulling everything together, here is a checklist you can work through when setting up or auditing your Mockupanda API key management:

• Create a separate key for development, staging, and production, named clearly in the dashboard

• Store each key in an environment variable; never hardcode it in source files

• Add .env to .gitignore before creating any .env file with real credentials

• Use your platform's secrets manager for staging and production environments

• Set a 90-day rotation reminder for all active keys

• Document which key is used by which service and environment

• Create temporary keys for testing or demos and schedule their revocation

• Build explicit error handling for INVALID_API_KEY and MISSING_API_KEY with immediate alerting in production

• If a key is suspected compromised, revoke it immediately in Dashboard, then API Keys, and check wallet transaction history for unexpected usage

• Review the Last Used timestamps on all keys quarterly and revoke any that are no longer in use

Managing credentials across environments is one of those things that feels like overhead until the day it saves you. The good news is that Mockupanda's key management tools are straightforward, there is no limit on how many keys you can create, and revoking a key is a single click. The structure is already there; it just needs to be used deliberately.