Managing and Rotating API Keys Securely

Your Model Database key, the one that starts with mdb_live_, is a credential that can spend your prepaid credit. Treating it carelessly is the single most common security mistake developers make with any API. This tutorial covers how to store keys safely, how to rotate them, and how to recover if one leaks.

The good news: the practices are simple, and most of them cost you nothing but a little discipline.

Never hardcode keys in source

The cardinal rule: a key should never appear in your source code or get committed to version control. Hardcoded keys end up in Git history, screenshots, and shared repos where they are nearly impossible to fully scrub. Instead, load keys from the environment:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://modeldatabase.com/v1",
    api_key=os.environ["MDB_API_KEY"],   # never the literal string
)

Set the variable outside your code:

export MDB_API_KEY="mdb_live_xxxxxxxxxxxxxxxxxxxxxxxx"

Use a .env file and ignore it

For local development, a .env file keeps secrets out of your shell history and organized per project. Critically, add it to .gitignore so it is never committed:

# .env
MDB_API_KEY=mdb_live_xxxxxxxxxxxxxxxxxxxxxxxx

# .gitignore
.env

Load it with a library like python-dotenv or Node's dotenv. Commit a .env.example with empty values so teammates know which variables are needed without exposing real secrets.

Keep keys off the frontend

Never embed your key in a browser app, mobile app, or any client-side code. Anything shipped to a user's device can be extracted. Instead, route requests through your own backend, which holds the key server-side and forwards calls to Model Database. The client talks to your server, and only your server talks to https://modeldatabase.com/v1.

Use separate keys for separate purposes

Create distinct keys for distinct environments and services, for example one for local development, one for staging, and one for production. This limits the blast radius if a single key leaks and makes it easy to revoke just the affected one. You manage all of your keys from your dashboard.

Rotate keys regularly

Rotation means replacing an old key with a new one on a schedule, so that even an undetected leak has a limited lifetime. A safe rotation process avoids downtime:

• Create a new key in the dashboard.
• Deploy the new key to your environment variables or secret manager.
• Verify traffic is flowing on the new key (watch the billing headers on live requests).
• Revoke the old key once nothing depends on it.

Because the key is read from configuration rather than code, rotating is just updating an environment variable and restarting, no code change or redeploy of source required.

Respond fast to a leak

If a key is ever exposed, in a public repo, a log, a pasted snippet, treat it as compromised immediately. Revoke it in the dashboard right away, then issue a replacement. Revocation is instant: a revoked key stops working, so the leaked credential can no longer spend your balance. Afterward, review your usage and balance to confirm nothing unexpected happened.

Verify which key is in use

Model Database returns X-MDB-Charged-USD and X-MDB-Balance-USD on every billable response. Watching the balance move on the expected key is a quick way to confirm your app is using the right credential after a rotation:

curl -i https://modeldatabase.com/v1/chat/completions \
  -H "Authorization: Bearer $MDB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openai/gpt-4o-mini","messages":[{"role":"user","content":"ping"}]}'

A 401 Unauthorized here means the key is wrong or revoked, exactly what you want to see after retiring an old key.

Use a secret manager in production

For production systems, store keys in a dedicated secret manager (such as your cloud provider's secrets service) rather than plain environment files. Secret managers add access control, audit logs, and encryption at rest, and they make rotation easier to automate across many services.

Secure key handling is mostly habit: load from the environment, never commit, rotate on a schedule, and revoke instantly when in doubt. Manage and rotate your keys at your dashboard, and review auth details in the docs.