---
title: "Create, replace and revoke API keys"
summary: "Manage credentials for your own tools and applications in Matilda’s web Settings."
url: https://help.maincode.com/products/matilda/v1/en/authentication/manage-api-keys
product: "Matilda"
kind: how-to
version: v1
source: MaincodeHQ/matilda-apps@44e52b188d4d324371ee5fb4bb094dc1789ea478
---

# Create, replace and revoke API keys

Manage credentials for your own tools and applications in Matilda’s web Settings.

## Choose the key type {#choose-the-key-type}

Sign in to your own account and open **Settings → API keys**. Keys belong to your personal account even when an organisation is selected. Organisation administration does not let you manage another member’s personal keys.

| Key type | Intended use | Current behaviour |
| --- | --- | --- |
| **Service — for applications** | Applications you build for their own users | Shares your personal account’s plan and usage allowance; expires after 90 days |
| **Personal — for your own use** | Your scripts and tools | Uses your personal account permissions and allowance; keys created here have no automatic expiry |

The current limit is 20 active keys of each type per customer, with an additional 20-active-key limit for an individual service account. An unavailable list is not an empty key list.

![API key Settings separates the key type, create form and metadata list. Only example prefixes are shown.](https://help.maincode.com/media/matilda/v1/en/b14781ce42e98d8763c9d2edab45e9dfbdc26be634474a4a1bd250f1a2a53b84.png)

## Create and save a key {#create-and-save-a-key}

1. Choose **Key type** and wait for the current keys to load.
2. Enter a descriptive **Key name**, then select **Create key** once.
3. In **Save your key now**, use **Copy API key**, or select and copy the value if clipboard access is unavailable.
4. Store it directly in your tool’s secure credential store or application secret manager.
5. Select **Done, stored it**.

Keep the full value out of client-side code, source control, screenshots, logs and support messages. Leaving or hiding the page clears the one-time view. Save before switching tabs. The later list shows metadata, not the recoverable secret.

## Replace a service key safely {#replace-a-service-key-safely}

1. Find the active service key and select **Replace key**.
2. Review the suggested name, then select **Create key**.
3. Save the replacement secret and update your application’s secret manager.
4. Verify the application is using the replacement before revoking the old key.

Replacement keeps the same service account. The original key stays active until you deliberately revoke it. Creating a new service key without **Replace key** creates a separate service account.

For a personal key, create another personal key, update your tool, verify it, then revoke the old one. These operations do not convert a key into an organisation credential.

## Revoke a key {#revoke-a-key}

Revocation is permanent. Requests using that credential will fail.

1. Select **Revoke** beside the intended active key.
2. Check its name in the confirmation, then **Revoke key**.
3. Refresh and verify its status is **Revoked**.

![The revocation dialog names the selected example key and explains its permanent effect.](https://help.maincode.com/media/matilda/v1/en/4e311fb53d2e675a96d9e45bd8b86b7cd6789478e3c94fb5308f56f7987daee4.png)

Revoking an old key does not revoke its separate replacement. Rotate any credential exposed outside its intended secure storage.

## Recover a lost response {#recover-a-lost-response}

A failed creation response can follow a created key. Select **Review keys** to inspect current metadata before another change. Matilda does not automatically repeat creation on reload.

If the key exists but its one-time secret was lost, deliberately revoke that key and create a replacement. Metadata and retries cannot recover the full value.

For uncertain revocation, refresh and check its current status before deciding whether to revoke again. On session expiry, sign in again and review the saved action. On account change, reload and verify the original account. If the active-key limit is reached, revoke an unused key, verify the result, then create the intended replacement.

If browser storage or request protection is unavailable, use the shown recovery guidance; do not open repeated creation attempts to work around an uncertain result.