Skip to content

Create API tokens

Organization API tokens let scripts, CI pipelines, and other systems call the Elaichi API without a browser session.

Where to find it: Settings → API tokens

You need api_token:create to create, list, and revoke your own tokens — built-in Member and above include it. Without any token permission, the tab shows that access is required. Seeing every token in the organization needs api_token:view; revoking someone else’s needs api_token:manage. Built-in Org Owner and Org Admin include both.

How tokens work

Property Behavior
Scope Bound to the current organization only
Permissions Act as the person who created the token — whatever their role in this org allows
Secret Shown once at creation; never viewable again
Revoke Immediate; clients using that token fail right away

Treat a token like a password for whoever created it. If that person’s role changes later, effective access of existing tokens follows their current membership permissions.

Create a token

  1. Open Settings → API tokens.
  2. Choose Create API token.
  3. Enter a Name that identifies where it will be used (for example CI pipeline or Inventory sync).
  4. Choose Create.
  5. Copy the token immediately. Acknowledge that you stored it securely, then choose Done.

The list shows name, created date, and last used (or Never). It never shows the secret again.

You'll know it worked when: The new row appears in the table and your client can authenticate with the copied value.

Warning

Anyone with the raw token can use this organization within the creator’s permissions. Store it in a secret manager — not in source control or chat.

Revoke a token

  1. On the API tokens list, choose Revoke for that row.
  2. Confirm. Elaichi asks you to confirm it’s you before the revoke completes.
  3. Update any clients that still embed the old value.

Revoke cannot be undone — create a new token if you still need access.

Good to know

  • Tokens are separate from SCIM tokens (provisioning only) and from your MCP endpoint, which authenticates over OAuth as you rather than a token.
  • Last used updates when the token successfully authenticates (throttled), so “Never” may simply mean unused.
  • Prefer a dedicated admin account on the least-privileged role that still does the job when minting automation tokens, so the token does not inherit broader Owner access than needed.