Available on every plan, Starter included. See Plans compared.
Before you click: the key is shown once
The plaintext key exists exactly once, in the screen that creates it. It is never shown again and cannot be recovered.
That is not a UI decision — only a one-way hash of your key is stored, so there is nothing to show you later. A database dump of TrueStat is not a set of working credentials.
If you lose a key, you create a new one and revoke the old one. There is no "show key" and there never will be.
Have somewhere to paste it before you click Create.
Steps
Name it after where it will be used
status-page, internal-dashboard, weekly-report-script. When you have
six keys, the name is the only way to know which is which.
Tick the permissions it needs
A grid of resources with a Read and a Write column. Ticking Write grants Read on the same row — a key cannot write to something it cannot read. The column headers tick or clear a whole column.
Choose which sites
All sites includes any site you add later. Untick it to name specific ones.
Choose an expiry
Never, 30 days, 90 days or a year. A key with no expiry works until it is revoked.
Create, then copy the key immediately
It is shown once and cannot be recovered.
What the key looks like
ts_live_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6...ts_live_ in production, ts_test_ against a test environment, then 48 hex
characters.
The prefix is deliberate. It makes a leaked key recognisable — a secret
scanner, a code review or a log grep can spot ts_live_ immediately. It also
means a leaked test key is visibly harmless.
Scoping
Sites. A key can be limited to specific sites. Name no sites and it reads every site in your organisation, including ones you add later. Name sites and it reads only those.
Scope to the narrowest set that works. A key on a public status page should read one site.
Permissions. Nine resources, each with a Read and a Write column — seventeen scopes in all, because Analytics has nothing to write: traffic is measured, not set. The scopes reference lists what each one opens.
Grant the narrowest set that works. Ticking Write grants Read on the same row, because a key cannot write to something it cannot read; the reverse does not happen, so a read-only key stays read-only.
There is no scope for creating API keys and no way for a key to widen itself. Keys are minted in the dashboard by an owner or admin, and only there — a credential that issues credentials turns one leak into permanent access.
Team management is narrower still: a key needs team:write and the person
who created it must be the account owner. An admin's key is refused.
Expiry. A key with an expiry stops working on that date, with no notice email. Set one for anything temporary; leave it off for a long-running integration you will remember to review.
After it is created
The key list shows, for each key:
| Name | What you called it |
| Prefix | The first 16 characters, so you can tell them apart |
| Permissions | As resource names, with a mark on the ones that carry Write |
| Sites | All sites, or how many |
| Created | |
| Last used | When it last authenticated a request |
| Expires / Revoked | If set |
Last used is the field to look at. It tells you whether a key is still part of something before you revoke it — which is the check that stops you taking down a production integration by tidying up. A key that has never been used shows "never used", which on an old key usually means it is pointing somewhere else.
Revoked and expired keys stay on the list, dimmed and labelled. The row is the record that the key existed, which is what an audit of "who had access" reads.
Changing a key
Edit changes a key's name, its permissions, its site scope and its expiry. The change takes effect on the key's next request — so removing a permission is the quickest way to narrow a key that is doing more than it should, short of revoking it.
What Edit cannot change is the key itself. Only a hash is stored, so there is nothing to show and nothing to replace. What a key means is editable; what it is, is not.
Revoking
Key list → the key → Revoke. It stops working immediately, on the next request.
Revoking is permanent and the key cannot be reinstated.
Rotating
There is no roll or rotate operation yet. To rotate:
Create a new key.
Deploy it wherever the old one was used.
Confirm the old key's "last used" has stopped moving.
Revoke the old key.
That sequence has no downtime, and step 3 is what makes it safe. A single-step rotation is on the list.
Keeping it safe
Server-side only. A key in browser JavaScript is a public key. Anyone can read it and query your analytics.
Environment variables, not source. A key in a repository is a key in everyone's clone and in your git history forever.
One key per integration, so revoking one does not break the others.
Review your keys when someone leaves the team. Keys belong to the organisation and keep working after their creator's account does not. See Removing someone.
If a key leaks
Revoke it first, investigate second. A revoked key is inert immediately.
Then work out what the exposure was, which depends on what the key carried. The key list shows its permissions, and that is the list to read first.
A read-only key exposed your figures and nothing else. A key with Write scopes could also have changed what those scopes cover — recorded goals, edited notes and alerts, changed site settings, or disconnected a payment provider. No key can delete a site, mint another key, or read back any credential.
So the check after a leak is scoped by the key: your goal list for entries you do not recognise, your alerts and site settings for changes you did not make, over the window the key was exposed.
Then create a replacement and deploy it.