Create and revoke your API keys

A key is how the API knows the account. This page issues one, shows what it has been spending, and takes it out of service. Two moments run one way: the secret is shown in full once, at creation, and a revoked key stays revoked.

​

API keys

A key is a secret token that authenticates a request. Keys begin with sm_ and travel in the x-api-key header on every call. Issue one per integration: that is what lets you revoke a leak without taking the rest of your business offline.

​

API key management

Keys live on the API keys page of the dashboard, the only place a key is issued, regenerated or revoked. The API reports the key behind the current request rather than the list: GET /api/v1/me returns an api_key block for the key that signed the call, which is how a deployed service confirms at boot that it holds the key you think it holds. Keys belong to the organization rather than to the member who created them, so a key issued by one Editor keeps working when another takes over the integration. Owners and Editors issue, bind and revoke keys; a Viewer sees the page without changing anything on it. Members covers the roles.

​

Create a key

Name the key after the thing that will hold it, not after yourself. A key called storefront-production tells you what breaks when you revoke it; key 2 does not, and the name is the only label the usage chart and the account endpoint give you when you decide which key to retire. The key is shown in full once, at creation. Copy it then and put it where the service that uses it reads its secrets. If you lose it, regenerate the key rather than issuing a second one beside it.

​

Read a key’s record

Every key carries a small record, and the account endpoint returns it for the key that signed the call: The last field is not a raw request count. It counts the operations that spend credits, which is the figure worth comparing against an invoice rather than against your own request logs.

​

Watch what a key spends

The chart above the list plots requests over time and can be filtered to a single key, which is the fastest way to answer two questions: whether an integration is actually calling, and which key is spending the credits. A key that has never been used says so rather than drawing an empty chart, so an integration deployed with the wrong secret shows up as silence.

​

Bind a key to a domain

A key can render to one of your custom domains. Set it here and every render made with that key serves its images from that domain, with nothing to pass per request. This is how one account serves two brands. Binding reads the plan before it offers itself, because custom domains are a paid-plan surface. Verify the domain first; the binding control on this page expects a domain that is already live.

​

Revoke or regenerate a key

Revoking a key stops it immediately and does not touch the others. It cannot be undone: the entry stays in the list as revoked, and a call made with it answers 401, the same answer a missing or malformed key gets. Regenerating issues a new secret for the same entry. That is the right move when a key leaked but the integration holding it should keep its identity: the entry stays, the secret changes, and you update one environment variable instead of rewiring a deployment.

​

API reference

• Retrieve the current account returns the api_key block for the key that signed the call, alongside the plan and the remaining credits
• Authentication covers where the header goes and what a rejected key answers
• Usage limits covers the request rate and the concurrency ceiling a key works inside
• Errors lists every status code and the error shape that carries it