Create and manage your Console API key credentials

Q: Can I rename an API key after I create it?

Yes. Choose Edit key in the row menu to change the name, the scope, or the expiration. The key value does not change. To replace a key that leaked, create a new one, move the integration onto it, then revoke the old key from its row.

Q: Can I see how many requests a key has left?

Yes, in the expanded row of the key, under Requests left.

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. Use this page to connect an external system to the platform, to limit what one integration can do, and to end an integration's access when it is retired. A key belongs to one organisation, your role there decides what it can do, and the key's scope sets only whether it can read, or read and write. Send the key in the X-Api-Key header. The platform does not accept it as a bearer token.

Your own sign-in and your wallet's signing authority are on Security: the PIN, recovery codes, two-factor authentication, passkeys and sessions. Scope enforcement, the rate limit and the errors a request can return are on Authenticate with API keys.

API keys page with three active keys in a table and a Create API key button — The table lists three keys with “Name”, “Scope”, “Status”, “Created” and “Last used” columns, and a masked preview of each key under its name.

Two keys are “Read only” and one is “Read & Write”, all “Active” and not used yet. The table toolbar holds a search box and a “View” control that reports two hidden columns, and the page header has the “Create API key” button.

Before you start

Set up a transaction PIN on Security if you do not have one. The Console cannot create a key until you have a transaction PIN or a transaction code and a confirmed set of recovery codes. Until then, “Create API key” opens the setup wizard.
If your deployment requires two-factor sign-in and your account signs in with a password or passkey, the platform refuses to create a key, or to widen one, with LOGIN_TWO_FACTOR_REQUIRED until you set up two-factor sign-in on Security. This applies in the Console and to dalp login. On a deployment with no identity provider configured, the Console sends you to set up two-factor sign-in before it opens any page. An account linked only to your identity provider, with no password or passkey, is exempt.
Switch to the organisation the key is for from the Organisation submenu of the account menu at the top right. The key stays with that organisation, and the Console has no control that moves an existing key to another organisation, so a second organisation needs its own key.
Decide the key's scope and expiration first: Choose a scope and an expiration compares the options. You can change both later with Edit key until the key expires, and the key value stays the same.
A key can act for you without a sign-in, so the Console asks you to confirm each new key with your transaction code, your identity provider code when you hold that authenticator instead, or your transaction PIN when you hold neither. Every new key sends you a security email. No key can be created during a cooling-off period, the hold on your signing that Security describes.

Steps

Create a key

Select Create API key and enter a name of up to 32 characters that identifies the integration. Once the name reaches 26 characters, the field shows a count against that limit. A longer name, typed or pasted, is refused with “That is over the 32-character limit, so nothing was changed.” instead of being cut. Spaces at the start or end of the name are not saved, and a name of only spaces shows “This field is required”. Then set the scope and expiration you decided on. The sheet opens on “Read & Write” and “Never”, so confirming without touching either control creates the widest, longest-lived key the Console offers. Select “Create API key”, then confirm with your transaction code, your identity provider code when you hold that authenticator instead, or your transaction PIN when you hold neither.

Create API key sheet with an empty name field, Scope set to Read & Write and Expiration set to Never — The “Create API key” sheet shows an empty “Name” field, “Scope” set to “Read & Write” and “Expiration” set to “Never”.

The sheet reads “Generate a new API key for programmatic access.” and notes what each scope allows. “Cancel” and “Create API key” sit at the bottom of the sheet.

Copy the key value now

The Console shows the full key value once, in the API key created dialog, with a copy button. Copy it into the integration or secret store that uses it before you close the dialog.

Review your keys

The table lists your keys for the organisation you are working in, with their name, scope, status, creation date, and last-used date. The status is “Active”, “Disabled”, or “Expired”. Each name shows a masked preview of its key value underneath. The “Key” column, which repeats that preview, and the “Expires” column are hidden at first. Show them from the table's column settings. Under the page description, “API reference” and “OpenAPI document” open your deployment's own API documentation in a new tab.

Edit, enable, or check a key

Open the row menu on a key. Edit key changes the name, the scope, and the expiration, and keeps the key value and its organisation. A new expiration counts from the day you save it, and “Keep current” leaves it as it is. Extend a key before its expiration date: once it expires, the platform deletes it at its next cleanup. A rename saves without your PIN or code. Changing the scope or expiration asks for your transaction code, your identity provider code when you hold that authenticator instead, or your transaction PIN when you hold neither, and the platform emails you about the change.

A key whose status is “Disabled” does not authenticate. Choose Enable in the row menu to turn it back on. “Enable” always asks for your transaction code, your identity provider code when you hold that authenticator instead, or your transaction PIN when you hold neither. The platform deletes keys that have expired at its next cleanup, so an “Expired” row leaves the table. Create a replacement for it.

Expand a row to see Requests left. Every key you create here has no request limit and shows “Unlimited”. A key that the platform has given a request limit shows the requests left in its current counting window and, under “Resets”, when the count starts again, or “Full budget available” when no window is running. A key with a fixed request total shows what remains of that total. Authenticate with API keys explains how the window counts.

Revoke a key

A revoke cannot be undone, so create a replacement before you revoke a key an integration still needs. Open the row menu on a key and choose Revoke. The Console asks “Are you sure you want to revoke” followed by the key's name, and warns that any application using the key loses access. Confirm to revoke it. The Console reports “API key revoked successfully.” and the row leaves the table. Requests with the key stop authenticating within 30 seconds.

Choose a scope and an expiration

A key belongs to one organisation. The Console issues the key for the organisation you are working in, and the platform resolves every request the key makes through that organisation. What the key can do there depends on your own role in that organisation. The key's scope sets only whether it can read, or read and write. Your keys are private to your account: another member of your organisation never sees them in this table.

A key acts for the participant your account is working as in this organisation. Without an X-Participant header, a key request follows your current Working as choice in the Console and picks up a change within 30 seconds. Send X-Participant on every request from an integration that must not move.

Read only

Can call only the routes the Platform API declares as reads, within your role's permissions. Any route that creates, updates, or deletes data refuses it, whatever HTTP method the request sends. Choose it for reporting, monitoring, or any integration that only reads data: a bug in that integration's code cannot turn into a write.

Read & Write

Can do everything your role allows in the organisation, on every route that accepts an API key. A request made with a key is not asked for wallet verification, so a Read & Write key signs transactions from your wallet without your PIN or transaction code. Treat its value like your PIN and your session together. Choose it only for an integration that creates, updates, or cancels something. A script that only pulls reports gains nothing from write access and carries more risk if the key leaks.

Expiration	What it costs	Choose it when
Never	The key keeps authenticating with no deadline. A leaked or forgotten key stays valid until you revoke it, and time alone never stops it.	You watch the key's “Last used” date and the audit trail, and you revoke the key yourself.
30, 60, or 90 days	The key fails on that date with the same authentication error as an invalid key. Issue and deploy the replacement before then, or the integration stops.	The integration's owner reviews and rotates its keys on a schedule, and a fixed deadline enforces that schedule.
1 year	The same fixed-date failure as the shorter options, further out. A leaked key stays valid for up to a year unless someone revokes it sooner.	The integration is long-running and low-risk and is reviewed once a year, so a 90-day rotation would only add work.

Choose an expiration that matches the integration's rotation schedule. Record who replaces the key before that date.

When your keys stop or keep working

Some changes to your account act on your keys without any step on this page:

Changing your password on Security, resetting it through the emailed link, or having a platform administrator set it for you turns off every key you hold, in every organisation. The keys stay in the table as Disabled until you enable them again. If the platform cannot turn them off, it refuses the new password and your old one stays in place, so a password change never leaves your keys on.
Leaving an organisation, or being removed from it, stops your keys for that organisation within 35 seconds. Their rows do not change.
During the cooling-off period after a wallet security change, your keys keep authenticating and reads keep working, but every request that signs a transaction returns 403 WALLET_VERIFICATION_HELD (DALP-17440) with heldUntil until the period ends. Retry after that time. No key can be created or turned back on, and no key's scope or expiration can change.
A platform administrator banning you stops your keys within 30 seconds until the ban ends. Closing your account stops them for good.
A platform administrator can revoke every key you hold, in every organisation, from your account page under Platform admin › Platform users. The keys stop within 30 seconds and leave your table. They cannot be turned back on, so create new ones if you still need API access.
A platform administrator ending your sessions leaves your keys working. To end a member's API access in one organisation, an organisation owner removes the member from the organisation, which stops their keys for it within 35 seconds.

Create a key from code or the command line

Authenticate with API keys documents key creation and management through the API, including request and response shapes. For command-line access, Install and set up the command-line tool explains how dalp login creates a key.

Troubleshooting

I closed the dialog before copying the key

The full value cannot be shown again: the table shows only a masked preview after creation. Revoke that key and create a replacement.

An integration using this key stopped working

Check the key's row first: its status, its scope, and its expiration in the expanded row. An “Expired” key, a “Disabled” key, a revoked key, and a key whose organisation you left all fail the same way, with DALP-14386, which looks like a wrong key. A “Disabled” key keeps its row. A revoked key leaves the table at once and an expired key at the next cleanup. A key for an organisation you left is in no table you can open. A read-only key sent to a write route fails with a distinct scope error, and a key the platform gave a request limit fails with a distinct rate-limit error once its window is full. Wait until the window resets. A new key does not help. Authenticate with API keys lists the exact codes. For the wrong scope, change it with Edit key, which keeps the key value. For an expired or revoked key, create a new key and 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 and names the key in the dialog, because any integration still using that key loses access within 30 seconds, and a revoke cannot be undone. Your other keys keep working.

All my API keys stopped working at once

A password change or reset turns off every API key you hold in that one step, and so does a platform administrator setting your password for you. It does not delete them. If every key failed around the same time, check whether your password changed recently on the Security page. The keys show as “Disabled”, so choose Enable in the row menu for the ones you still need before you reissue anything. Enabling restores the same key without a redeploy.

Frequently asked questions

Can I rename an API key after I create it?

Yes. Choose Edit key in the row menu to change the name, the scope, or the expiration. The key value does not change. To replace a key that leaked, create a new one, move the integration onto it, then revoke the old key from its row.

Can I see how many requests a key has left?

Yes, in the expanded row of the key, under Requests left.

Does an API key expire on its own if I never use it?

No. Expiration is a fixed date set when you create or edit 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 with no use at all, until you revoke it.

Can I search for one key if my account has built up a lot of them?

Yes. The table has a search box, column sorting, and filters. The search runs on the keys the table has loaded.

API routes

Key management runs under /api/auth/api-key/*, not /api/v2: create, list, read one, update and delete. Authenticate with API keys documents each route with its request and response shapes. For command-line access, Install and set up the command-line tool explains how dalp login creates a key.