01What is an API key?
An API key is a long, random string that an API provider issues to a customer account so that the customer's servers can authenticate their requests. The key travels with every call, usually in a header such as Authorization: Bearer … or X-API-Key, and the provider looks it up to decide which account is calling and what it may do. Many messaging and CPaaS providers use API keys for sending SMS, WhatsApp and email through their own REST APIs.
An API key is a bearer credential with no person attached to it and, usually, no expiry: whoever presents it is treated as you. That simplicity is both the appeal and the risk. A key committed to GitHub, pasted into a support ticket or bundled into a mobile app can be used by anyone, from anywhere, until someone revokes it.
It is not the same as an access token on the WhatsApp Cloud API. Meta does not issue API keys for the Graph API; it issues tokens to a user or a system user, with explicit permissions such as whatsapp_business_messaging and, for user tokens, an expiry. Providers that sit in front of the Cloud API often give you an API key for their own platform and hold the Meta token on their side. Delegated access between companies belongs to OAuth 2.0, not to shared keys. And a key only authenticates calls you make: for calls a provider makes to you, such as webhooks, the check runs the other way, with a signature header or webhook mTLS (mutual TLS).
Key takeaways
- An API key is a static secret that identifies and authenticates your server to a provider's API.
- Whoever holds the key can call the API as your account, so treat it exactly like a password.
- Keep keys server-side only: never in browser JavaScript, mobile apps, URLs or public repositories.
- Meta's WhatsApp Cloud API does not use API keys; it uses access tokens issued to a user or system user.
- Scope each key narrowly, rotate it with an overlap period and revoke it the moment it may have leaked.
02An API key in code
# Illustrative provider endpoint: the key comes from the environment, never the command history.curl -X POST "https://api.provider.example/v1/messages" \-H "Authorization: Bearer $PROVIDER_API_KEY" \-H "Content-Type: application/json" \-d '{"channel":"whatsapp","to":"919812345678","template":"class_reminder","params":["Physics","5 pm"]}'
Keys belong in a header over HTTPS. Load them from a secret store into the environment at deploy time.
03 · How it works, step by step
How does an API key work?
- Step 1
Create one key per purpose
Generate separate keys for production, staging and each service or integration, so a single leak or revocation never takes everything down. Name each key after its owner and use.
- Step 2
Scope it narrowly
Where the provider allows it, restrict each key to the operations it needs (send only, read-only reports), to specific sender numbers and to your servers' IP addresses, following the principle of least privilege.
- Step 3
Store it as a secret, inject it at runtime
Keep the key in a vault or cloud secret store, load it into the process environment at deploy time, and never write it into source code, logs, URLs or client bundles.
- Step 4
Send it over HTTPS, in a header
Put the key in the
AuthorizationorX-API-Keyheader. Never put it in a query string, where proxies, browser history and access logs record it. - Step 5
Rotate and revoke
Issue the new key, deploy it, confirm traffic has moved, then revoke the old one. Revoke at once on any suspected exposure; token rotation covers the overlap pattern in detail.
04 · Common mistakes, and the fix
Common mistakes with an API key
Shipping the key in front-end or mobile code
Anything in a browser bundle or app binary can be extracted in minutes. Put a small backend in front of the provider and have clients call it with their own user session.
Committing it to a repository
A key stays in Git history after the file is changed. Use secret scanning in CI and keep keys in a vault; if one is committed, revoke it, because deleting the commit is not enough.
One key for everything
A single shared key means one leak exposes every environment and every rotation risks an outage. Issue keys per environment and per service.
Putting the key in the URL
Query strings end up in access logs, proxy logs and analytics tools. Send keys in a header over HTTPS only.
05An API key: key facts and limits
- Typical header
- Authorization: Bearer <key> or X-API-Key
- Randomness
- At least 128 bits; 32 random bytes is common
- Expiry
- Usually none unless you rotate or set one
- Where it belongs
- Server-side only, loaded from a secret store
- Meta Cloud API
- Uses access tokens, not API keys
- Never put it in
- URLs, logs, client apps, screenshots or tickets
06Why does an API key matter?
API keys are one of the most common ways messaging integrations get abused. A leaked key lets an attacker send messages at your expense, read conversation data or drain a prepaid balance, and it usually goes unnoticed until the bill or a customer complaint arrives. Handling keys well (scoped, kept in a secrets management tool, rotated on a schedule and monitored) is a small amount of engineering that removes a whole class of incident.
07Example: A leaked key that hit a wall
A developer at a Hyderabad edtech company accidentally pushes the production key for its messaging provider to a public repository. Within minutes an automated scanner finds it and starts calling the send endpoint. Because the key was restricted to the company's two server IP addresses, every call from the attacker's machines is rejected with 403, and an alert on the burst of rejected requests pages the on-call engineer. She revokes the key, deploys its replacement from the vault and adds secret scanning to CI. The company's other services, which use keys of their own, never notice.
08 · Tips from the bench
Best practices for an API key
- Prefix keys by environment (live_, test_) so a misplaced key is easy to spot and to scan for.
- Alert on unusual usage: new IP ranges, sudden volume spikes or calls at odd hours.
- Record who created each key and when it was last used, and delete keys nobody has used for 90 days.
- If you issue keys yourself, store only a hash and show the full key exactly once.