Give each service its own key, and make it a restricted key whenever your vendor offers that type. Fall back to a standard key only if restricted access is not available for the resources you need. Keep the full access main credential out of application code, and revoke any key the moment its job ends.
How one vendor describes the three types
Twilio's API key documentation lists three types:
| Type | Access |
|---|---|
| Main | Full access to all API resources, equivalent to using the account SID and auth token |
| Standard | Access to all API resources except the Accounts and Keys resources |
| Restricted | Customized, fine grained access to specific API resources |
The page also advises issuing separate keys to different developers or subsystems, revoking a key that is compromised or no longer used, and using Restricted keys for minimum and specific access. It notes that Main keys can be created in the console but not through the REST API, and that Restricted key creation through the API is for v1 of the Key resource.
Other providers use different names for the same idea, such as restricted keys for payments. The pattern is the same everywhere: the more a key can do, the more it can cost you when it leaks. See also publishable vs secret vs restricted payment API keys.
A decision guide
- Write down what the service needs to call. Sending messages, reading delivery status, nothing else?
- Choose the narrowest key type that covers that list. If a restricted key can express it, use it.
- Create one key per service and per environment. A staging worker and a production worker never share one.
- Name keys after their owner and purpose. "billing-notifications-prod" beats "key2".
- Store the secret once, in a vault. Most consoles show the secret only at creation.
- Set a review date. Revisit each key when the service changes.
Why per-service keys matter in an incident
Say a notification worker leaks its key. If every service shares one key, you must rotate it everywhere at once, and some services will break while you scramble. If each service has its own, you revoke one key, deploy a replacement, and the others keep running. The first hour after a leak is much calmer. The steps are in how to rotate leaked API keys.
What a restricted key cannot save you from
A narrow key still sends messages. If your key can send, an attacker with it can send too, which can mean fraud, spam or traffic pumping charges. Keep a spending or volume alert in the vendor console and watch usage logs. Scope limits damage; monitoring finds it.
What to avoid
- A single main credential shared by every environment.
- Keys in source files, container images or chat threads.
- Keys with no owner, so nobody dares delete them.
- Leaving old keys active after a migration.
Where Safeguard fits
Safeguard's asset discovery and compliance evidence automation can help you keep an inventory of integrations and show which controls cover them. You can start with a free scan.
Quick check
Is a standard key safe enough for production?
It is narrower than a main key but still broad. Prefer restricted where possible, and monitor usage either way.
How many keys should one app have?
One per service and environment, so you can revoke one without touching the rest.
Sources
- API keys, Twilio documentation
Last reviewed: 19 October 2026.
