# API Keys

### Viewing your keys

When you open the API Keys page, you see a table of all your existing keys with the following columns:

<table><thead><tr><th width="217">Column</th><th>Description</th></tr></thead><tbody><tr><td><strong>Name</strong></td><td>The friendly name you gave the key when creating it</td></tr><tr><td><strong>Key</strong></td><td>The publishable key prefix (e.g. <code>pk_test_abc...</code>)</td></tr><tr><td><strong>Environment</strong></td><td><code>test</code> or <code>live</code></td></tr><tr><td><strong>Scopes</strong></td><td>The permissions granted to this key</td></tr><tr><td><strong>Status</strong></td><td><code>Active</code> or <code>Inactive</code></td></tr><tr><td><strong>Created</strong></td><td>When the key was created</td></tr></tbody></table>

Click any row to open the key details modal.

### Creating a new key

1. Click the **Create API Key** button in the top right
2. In the modal that appears, fill in:
   * **Name** — a descriptive name so you can identify this key later (e.g. "Production Backend", "Staging Server")
   * **Environment** — choose `test` for development or `live` for production
   * **Scopes** — select which permissions the key should have. By default, all scopes are selected. You can toggle individual scopes:

<table><thead><tr><th width="217">Scope</th><th>What it allows</th></tr></thead><tbody><tr><td>Full Access</td><td>Access all resources (quotes, transfers, recipients)</td></tr><tr><td>Quotes - Read</td><td>Get quotes only</td></tr><tr><td>Quotes - Write</td><td>Create and manage quotes</td></tr><tr><td>Recipients - Read</td><td>View recipient details</td></tr><tr><td>Recipients - Write</td><td>Create and update recipients (KYC/KYB)</td></tr><tr><td>Transfers - Read</td><td>View on-ramp and off-ramp transfers</td></tr><tr><td>Transfers - Write</td><td>Create on-ramp and off-ramp transfers</td></tr></tbody></table>

3. Click **Create Key**

{% hint style="danger" %}
After creation, a success modal displays your **secret key** (`sk_test_...` or `sk_live_...`). This is the only time the secret key is shown. Copy it immediately and store it securely. You cannot retrieve it again.
{% endhint %}

### Managing an existing key

Click on any key in the table to open the details modal. From here you can:

#### Activate or deactivate

Toggle a key between `Active` and `Inactive` status. Inactive keys are immediately rejected by the API. This is useful if you suspect a key has been compromised, you can deactivate it instantly without deleting it.

#### Regenerate the secret

If your secret key has been exposed, click **Regenerate** to issue a new one. The old secret is invalidated immediately. A success modal shows your new secret, copy it before closing.

{% hint style="warning" %}
After regenerating, update your application with the new secret immediately. Any requests using the old secret will fail.
{% endhint %}

#### Delete a key

Click **Delete** to permanently revoke a key. You will be asked to confirm this action. Once deleted, the key cannot be reactivated or recovered. Any API calls using this key will return a `401 Unauthorised` error.

### Best practices

* **Use separate keys for test and live** — never use a test key in production or vice versa
* **Use the minimum scopes needed** — if a service only reads quotes, give it `quotes:read` only
* **Name your keys descriptively** — "Mobile App Backend" is more useful than "Key 1" when you need to identify which key to rotate
* **Rotate keys periodically** — use the regenerate feature to issue new secrets on a regular schedule
* **Deactivate before deleting** — if you are unsure whether a key is still in use, deactivate it first and monitor for errors before permanently deleting


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.zynta.com/dashboard/api-keys.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.