API keys

The API Keystab issues bearer tokens for the Zubby AI public REST API. Use them to read your store’s data — orders, customers, conversations — from your own scripts and integrations. Find it under Settings → Integrations → API Keys, or go to /app/<storeId>/settings/api-keys. The card is titled Public API keys.

The secret is shown exactly once

When you create a key, the full token is displayed a single time, right after creation. Zubby stores only a hash of it — once you navigate away it cannot be recovered. Copy it immediately and store it in a secret manager. If you lose it, revoke the key and mint a new one.

Creating a key

Click Create key to open the form. You provide:

Name— a label so you can recognize the key later (e.g. analytics-export). Required, up to 120 characters.
Scopes— what the key is allowed to do. Pick at least one:
- read— GET endpoints (orders, customers, conversations). Checked by default.
- write— mutating endpoints. Limited and admin opt-in; leave it off unless an integration genuinely needs to write.

Submit with Create key. A green banner shows the new token with a Copy button; click Done once you’ve saved it. If you pick no scopes, the form refuses with “Pick at least one scope.”

The key list

Existing keys appear below the create form. Each row shows:

Name and the key prefix(the first few characters, followed by an ellipsis) — enough to identify a key without exposing the secret.
A status badge: active or revoked.
The scopes the key carries, as badges.
When it was created, and either when it was last usedor “never used.” Revoked keys also show their revocation time.

Revoking a key

Active keys have a Revokebutton. Revoking is immediate and permanent — the dashboard warns that “existing requests using this key will start failing immediately.” You’ll be asked to confirm. Revoked keys stay in the list for audit history but can no longer authenticate.

Using a key

The public API authenticates with the bearer token plus your store ID. Treat keys like passwords: never commit them to source control, scope them to the minimum (read only where possible), and use a distinct key per integration so you can revoke one without breaking the others.

Key hygiene

Name keys after the system that uses them so an unfamiliar key on the list is an immediate red flag.
Rotate periodically: mint a replacement, cut the integration over, then revoke the old one.
Check the last usedtimestamps and revoke anything that hasn’t been used in a long time.

For the endpoints these keys unlock, see the REST API reference. For event- driven integrations, see Webhooks. Widget embed credentials are separate — those live on the Workspace tab and are covered in Settings overview.

API keys

The secret is shown exactly once

Creating a key

Click Create key to open the form. You provide:

Name— a label so you can recognize the key later (e.g. analytics-export). Required, up to 120 characters.

Scopes— what the key is allowed to do. Pick at least one:

read— GET endpoints (orders, customers, conversations). Checked by default.
write— mutating endpoints. Limited and admin opt-in; leave it off unless an integration genuinely needs to write.

The key list

Existing keys appear below the create form. Each row shows:

Name and the key prefix(the first few characters, followed by an ellipsis) — enough to identify a key without exposing the secret.

A status badge: active or revoked.

The scopes the key carries, as badges.

When it was created, and either when it was last usedor “never used.” Revoked keys also show their revocation time.

Revoking a key

Using a key

API keys

Creating a key

The key list

Revoking a key

Key hygiene

Related

API keys

Creating a key

The key list

Revoking a key

Key hygiene

Related