Skip to main content
Keys are issued from the API Keys page of your dashboard. The full value is shown once, right after creation — save it then. Afterwards you will only see its first six characters, enough to tell your keys apart in a list. A key you have lost cannot be recovered, only revoked andAPI Keys page of your dashboard. The full value is shown once, right after creation — save it then. Afterwards you will only see its first six characters, enough to tell your keys apart in a list. A key you have lost cannot be recovered, only revoked and replaced.

​
What a key looks likeWhat a key looks like

The tsl_live_ prefix is stable, which means secret scanners can be taught to recognise it. If you keep configuration in a repository, it is worth enabling that.

​
Rules

  • Header only. The key is never accepted as a query parameter, since query strings leak into places you do not control.
  • Server-side only. Cross-origin browser calls to /v1 are not permitted. A key shipped in a frontend bundle can be read by any visitor.
  • Several keys per account. Your plan sets how many are active at once. More than one is what makes rotation possible without downtime: issue, deploy, then revoke. They share one quota rather than adding to it — see Rate limits.
  • No expiry, and version-neutral. The same key works on /v1 and on any future major version, so migrating means changing a URL, not reissuing a secret.

​
Plan changes and suspension

A downgrade revokes nothing. We check the plan on every request, so the key simply starts returning 403 api_access_not_available_on_current_plan, and it works again the moment you return to a plan that includes the API. The same is true of a suspended account, which returns 403 account_suspended.

​
Failures

A missing, malformed, revoked or unknown key all return 401 invalid_api_key. The response does not tell you which of those it was — if it did, it would help someone guessing at keys narrow the search. Repeated rejected requests from one address are throttled with a 429, so check the key rather than retrying.
The tsl_live_ prefix is stable, which means secret scanners can be taught to recognise it. If you keep configuration in a repository, it is worth enabling that.

​
Rules

  • Header only. The key is never accepted as a query parameter, since query strings leak into places you do not control.
  • Server-side only. Cross-origin browser calls to /v1 are not permitted. A key shipped in a frontend bundle can be read by any visitor.
  • Several keys per account. Your plan sets how many are active at once. More than one is what makes rotation possible without downtime: issue, deploy, then revoke. They share one quota rather than adding to it — see Rate limits.
  • No expiry, and version-neutral. The same key works on /v1 and on any future major version, so migrating means changing a URL, not reissuing a secret.

​
Plan changes and suspension

A downgrade revokes nothing. We check the plan on every request, so the key simply starts returning 403 api_access_not_available_on_current_plan, and it works again the moment you return to a plan that includes the API. The same is true of a suspended account, which returns 403 account_suspended.

​
Failures

A missing, malformed, revoked or unknown key all return 401 invalid_api_key. The response does not tell you which of those it was — if it did, it would help someone guessing at keys narrow the search. Repeated rejected requests from one address are throttled with a 429, so check the key rather than retrying.