Not available yet. Key generation, hashing and validation are built; the management screen is not. This page describes the intended behaviour.
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.
The key-creation result showing the full plaintext key with a copy button and the prominent "this is the only time you will see this" warning. Use a clearly fake key. Light theme, desktop. Capture once the feature ships.
Steps
Settings → API keys.
Create key.
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.Optionally scope it to specific sites. A key with no sites named can read every site in your organisation.
Optionally set an expiry date. A key with no expiry works until revoked.
Create, then copy the key immediately.
Owners and admins can create keys. See Roles and permissions.
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.
Read-only. Every key is read-only, by construction rather than by a setting. There is no write scope to grant and no way to widen one.
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 |
| Sites | What it can read |
| Created | |
| Last used | When it last authenticated a request |
| Expires | 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.
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, and the read-only construction means the exposure is limited to your analytics being readable — no data could have been changed, no setting altered, no site deleted.
Then create a replacement and deploy it.