Skip to main content
Every request carries an API key, in the Authorization header:
A key belongs to one workspace: everything it reads or changes is in that workspace, and nothing else. GET /v1/me says which key you called with and which workspace it opens.

​
The two kinds of keys

A change made with a Read only key is refused with 403 and the code cle_de_lecture. Pick Read only whenever your tool only reads: a key that can’t change anything can’t break anything either.

​
Creating and revoking keys

Keys are created and revoked in the console, in Settings › API, by the workspace owner — never through the API: a key can’t create or revoke a key, not even itself.
  • A key is shown once, when you create it. TIKT keeps only a fingerprint of it, never the key itself: no one at TIKT can show it to you again. If you lose it, revoke it and create another one.
  • Up to 10 active keys per workspace. A revoked key no longer counts.
  • Keys don’t expire. The list shows when each key was last used (to the minute), so you can revoke the ones nobody uses any more.
  • A revoked key is refused from the next request (401, cle_revoquee).
  • When a workspace is scheduled for deletion, its keys are revoked.

​
Keep keys safe

  • One key per tool. If a tool is compromised or retired, you revoke its key alone; the others keep working.
  • Server to server only. Never call the API from a browser, a web page or a mobile app: anyone could read the key in the page. The API sends no CORS headers, so browsers refuse its answers anyway.
  • Store keys in your tool’s secret store or in environment variables, never in a shared document or in your code’s repository.
  • If a key leaks, revoke it in Settings › API — it stops working at once.

​
When a key is refused

See Errors for the shape of every error.