Sharing one API key across a team: how to manage it

What goes wrong with one shared key

• No attribution: you cannot tell who used how much, so you cannot allocate cost
• No incident tracing: someone writes an infinite loop and burns the quota, and you cannot find out who
• No individual revocation: to stop one person you have to stop everyone

These problems get genuinely painful once usage grows.

Option one: one key per project (the simplest)

If the site allows creating multiple keys (most do), hand them out per project or per person.

Pros: zero cost, possible immediately Cons: you only learn "which key used how much", and many keys become hard to manage Fits: small teams (3-5 people) with clear project boundaries

Option two: your own middle layer (the most control)

Put a self-hosted gateway (One API, LiteLLM and similar) between the team and the target site:

member -> self-hosted gateway (issues sub-keys + quotas + logs) -> upstream

What you get:

The cost: a server plus maintenance. When it is worth it: five people or more, or usage large enough that you have to know where the money goes.

Option three: a commercial gateway service

If you would rather not maintain one yourself, hosted gateway services exist. The trade-off is similar, with the maintenance cost replaced by a monthly fee.

The habits that go with it

One: keys never go into the repository.

# Never do this
api_key = "sk-xxxxxxxx"
# Do this instead
api_key = os.environ["API_KEY"]

Keys stolen through a leaked repository are a common incident. Once a key has been committed, revoke it in the site's console and create a new one immediately.

Two: annotate every key with its purpose. Write down what it is for and who owns it, so that six months later you can still tell whose key is whose.

Three: use a separate key and a low cap for development. Debug traffic is often heavy; give it its own key with a low quota so it cannot eat into your production allowance.

Four: clean up unused keys regularly. Revoke keys when someone leaves, a project ends, or a temporary test is over. The more keys that exist, the wider the exposure.

Five: set up a usage alert. At minimum, have something that notifies you when usage passes a threshold. Even a weekly human glance beats no monitoring at all.

A risk that is easily missed

A team member's own device can leak a key. Someone puts it in a local script, pastes it into a chat, or commits it to a public repository.

How to handle it: prefer issuing sub-keys through your own gateway (individually revocable, so the blast radius is small); agree that keys never go into any file that leaves the team; and rotate them periodically.

Related reading

• Wiring a relay service into Dify or FastGPT
• How to configure several API providers as mutual fallbacks
• Account throttled or banned: the common triggers for relay service risk controls