What an extra Massive API key does not do is give you more capacity. Every key on an account reads the same subscriptions, so it inherits the same per-asset-class request limits and the same WebSocket connection allowance. That is why generating a second key never lifts a 429. What keys are for is separation: revoking one without touching the others.
Applies to
- Plans: every plan, including the free Basic tier.
- Endpoints: a key works across REST, the WebSocket clusters and the flat files, subject to the account's subscriptions.
- Asset classes: all. Entitlement is per account, not per key.
How to manage your keys
- Open the keys page of your dashboard.
- Create a key, and name it for where it will run. The name is the only way to tell them apart later.
- Delete a key when the thing using it is retired. Deletion is immediate and the key stops working, so check nothing is still using it. An account holds at most 100 active keys, so deleting retired ones is housekeeping rather than a formality.
Deleting and recreating a key does not reset a rate limit or clear an entitlement problem, because neither belongs to the key. Both follow the account's subscriptions, one per asset class.
What a second key is and is not good for
A second key is good for operational separation and not for extra capacity:
| What you might want | Does a second key help? |
|---|---|
| Separate production from a local script | Yes. Revoke one without redeploying the other |
| Rotate credentials without downtime | Yes. Add the new key, deploy, delete the old one |
| Know which integration is making the requests | Yes, through the usage view per key |
| More than 5 requests a minute on an asset class you have not bought | No. The limit follows the subscription, not the key |
| A second simultaneous WebSocket connection | No. Connections are counted per account per cluster |
| Access to an asset class you have not subscribed to | No. Entitlement is per account |
Why entitlement is per account
Entitlement is per account because subscriptions are what you buy and a key is only a credential pointing at them. That is deliberate: it means an upgrade applies to every key you already have, with nothing to regenerate or redeploy, and it means a compromised key can be deleted without disturbing the subscription.
If you see an error
{"status":"ERROR","error":"Unknown API Key"} with HTTP 401 means the key was deleted or mistyped. Copy it again from the keys page.
A 429 that persists after making a new key is the rate limit on that request's asset class, not a key problem. Check whether you hold a paid plan for the asset class you are querying.
NOT_AUTHORIZED on a new key that works on an old one is not possible, because both carry the same entitlements. Check the request rather than the key.
