API keys
Create and manage the API credentials that authenticate Platform API requests on your behalf, without a signed-in Console session.
API keys is where you create and manage the API credential values that let a script, service, or integration call the Platform API as you, without a signed-in Console session. Reach for this page whenever you need to connect an external system to the platform, when you want to limit what a given integration can do, or when an integration is retired and its access needs to end.
This page is the wrong choice for two neighbouring jobs. If you want to protect your own sign-in and your wallet's signing authority, that is Security, which owns the PIN, recovery codes, two-factor authentication, passkeys, and sessions. If you already hold a key and need to send it correctly from code, that is Authenticate with API keys, which owns the header name and the errors a bad key returns.
An API key is independent of your wallet security. You can create one before you have set up a PIN or recovery codes, because authenticating a Platform API request with a key is a different step from signing a transaction. The key is bound to an organisation. The Console issues the key against the organisation you are working in, and the Platform API resolves every request through that organisation, so a key that carries no organisation authenticates nothing at all. What the key can do once it authenticates still depends on your own account's permissions; the key itself only decides whether it can read, or read and write. An API key is also private to your own account on this screen: it never appears in this table for another member of your organisation. Revoke your keys from their rows on this page.
Read only
Blocks every route the Platform API has declared read-write, whatever HTTP verb the request itself sends. A Read only key can call routes declared read-only within your account's permissions. It cannot call routes that create, update, or delete data. Choose it for reporting, monitoring, or any integration that only ever reads data, since a read-only key cannot be misused for a write even if the integration's own code has a bug.
Read & Write
Carries your account's full permissions in the organisation, the same access you have signed in through the Console yourself. Choose it only for an integration that genuinely creates, updates, or cancels something. A script that only pulls reports gains nothing from write access and carries more risk if the key ever leaks.
| Expiration | What it costs | Choose it when |
|---|---|---|
| Never | The key keeps authenticating with no deadline. A leaked or forgotten key stays valid until a person notices and revokes it by hand; nothing about time alone stops it. | The integration is one you actively monitor, so you would notice a compromise quickly and can revoke fast. |
| 30, 60, or 90 days | The key fails, with the same generic error as an invalid key, the moment the date passes. You have to reissue and redeploy the replacement before then or the integration goes dark. | Whoever owns the integration reviews and rotates its keys on a schedule, so a forced deadline is a feature rather than an outage waiting to happen. |
| 1 year | The same fixed-date failure as the shorter options, further out. A leaked key stays valid for up to a year if nobody catches it sooner. | The integration is long-running and low-risk, reviewed on an annual cycle, where a 90-day rotation would be pure overhead. |
Choose an expiration that matches the integration's rotation schedule. Record who will replace the key before that date.
Steps
Open API keys
Open the account menu in the Console's top bar and select API keys. The table lists every key on your account: its name, a masked preview of its value, its scope, when it was created, when it was last used, and when it expires.
Screen equivalent: the page lists your API keys in a table with name, masked key, scope, created, last used, and expires columns, alongside a Create API key button.
Create a key
Select Create API key, enter a name that identifies what will use it, then set the scope and expiration you decided above. The sheet opens preselected on Read & Write and Never, so confirming without touching either control creates the widest, longest-lived key the Console offers; confirm only once both match what you decided.
Copy the key value now
The Console shows the full key value exactly once, in the confirmation dialog, with a copy button. Copy it into the integration or secret store that will use it before you close the dialog.
Create a key from an integration
Authenticate with API keys documents key creation and management, including request and response shapes. For command-line access, follow the CLI installation guide.
Troubleshooting
I closed the dialog before copying the key
The full value is gone for good; the table only ever shows a masked preview after creation. Revoke that key and create a replacement rather than searching for a way to reveal it again.
An integration using this key stopped working
Check the key's row in the table for its expiration date and scope first. An expired key, a revoked key, and a key whose organisation membership has ended all fail the same way, with a generic authentication error indistinguishable from a wrong key. The table, not the error, is where you find out which one happened. A read-only key used against a write request fails differently and more usefully, with a distinct scope error naming the mismatch; Authenticate with API keys has the exact codes. If neither explains it, the key may be calling too often: each key carries its own request budget, counted separately from every other key on your account, so one busy integration cannot exhaust another's headroom. That failure also names itself distinctly, and backing off until the window resets is the fix, not a new key; Authenticate with API keys has the window and request-count values. For an expired, revoked, or wrong-scope key, create a new one with the right scope and expiration, then update the integration to use it.
I need to shut off access for one integration without touching the others
Revoke only that integration's key from its row. Revoking asks you to confirm, since any application still using that specific key loses access immediately and cannot be undone. Your other keys keep working unaffected.
All my API keys stopped working at once
Changing your Console password disables every API key on your account in that one step, not just the session you were using; it does not delete them. If every key failed around the same time, check whether your password changed recently on the Profile page. The keys still exist, so re-enable the ones you still need through the reference's update call before you reissue anything: setting a disabled key back to enabled restores it without a redeploy.
Frequently asked questions
Can I rename an API key after I create it?
No. The Console has no control that edits an existing key's name, scope, or expiration; use the API management endpoints to edit them in place. If a name stops describing what uses it, or the scope or expiration turns out wrong, create a replacement with the values you want, move the integration onto it, then revoke the old key from its row in the table.
Does an API key expire on its own if I never use it?
No. Expiration is a fixed date set when you create the key, never a measure of activity. A key set to expire in 90 days stops authenticating on that date whether it made one request or ten thousand. A key set to never expire keeps working indefinitely with no use at all, until someone revokes it by hand.
Can I search for one key if my account has built up a lot of them?
Yes. The table carries a search box and per-column sorting and filtering, including on scope and expiration, so a long list of integrations stays navigable once scrolling through it by eye stops being practical.