API keys

/account/api-keys · staff

Personal API keys let you call the Atlas API from scripts and services without a browser session. Key issuance is restricted to staff and admin accounts — this is a deliberate decision, not an oversight: keys are long-lived credentials, so they stay with operationally trusted users.

TIP

Not to be confused with the RIPE Atlas API key on your profile, which is a credential for RIPE, not for this platform.

What a key looks like

atlas_pk_3qX2f8LmNp4RtVw7YzB1cD5eG9hJkM2n

The atlas_pk_ prefix is stable and deliberate — it makes Atlas keys recognisable at a glance to code review, secret scanners and log filters. The rest is 192 bits of randomness from the OS.

Creating one

Give the key a label describing where it will be used — "Grafana sidecar", not "key 2". The label is the only thing distinguishing keys later, when you are deciding whether one is safe to revoke.

You can also set an expiry. Keys are otherwise valid until revoked.

The secret is shown exactly once

Only a SHA-256 hash of the key is stored. Atlas cannot show you the secret again, cannot recover it, and cannot tell you whether the one in your config is the right one. Copy it into your secret store before leaving the page — a lost key means issuing a new one.

Afterwards, a key is identified in the UI by its prefix — the first 16 characters — along with its label, creation date, and when and from which IP it was last used.

Scopes

Two scopes: read and write. Every key includes read; asking for write adds it. There is no write-only key, and there is no narrower scope than "all reads".

Default to read-only. Most integrations — dashboards, exporters, scripts that pull numbers — never need to write.

Using a key

See API → Authentication for the exact header.

Last used

Each key records when and from what IP it was last used. This is the field to check before revoking something you no longer recognise: a key with no recorded use is safe to remove, and one used from an address you don't expect is worth investigating immediately.

Rotating without downtime

Because keys are independent rows, rotation needs no maintenance window:

1. Create a new key with the same scopes and a label saying what it replaces.
2. Deploy the new secret.
3. Confirm the old key's last used timestamp has stopped advancing.
4. Revoke the old key.

Revoking

Revocation takes effect immediately — the next request with that key fails. Revoke as soon as you suspect exposure; there is no cost to issuing a replacement.

Admins can revoke any user's key from the admin panel, which is the recovery path when a secret turns up somewhere it shouldn't be and its owner is unavailable.