Most teams that automate Threaded start by copying a person’s session or asking someone to click through the app on a schedule. That couples CI and cron jobs to a human account, and it makes revocation messy when that person leaves.
Threaded API Tokens are organization-owned machine credentials. Owners create a named token (for example GitHub Actions), copy a secret once, and use it as Authorization: Bearer thr_sat_…. The token can view and edit work in the organization the way an editor can. It cannot manage owners or members, cannot mint more tokens, and cannot use the AI Assistant.
#Key Concepts
Named token A label you choose (CI, a partner, a nightly job). One name can have several secrets over time.
Secret The thr_sat_… value shown only once. Store it in your secret manager. Threaded stores a hash, not the plaintext.
Editor-level access Active tokens can read and write organization work (instructions, issues, media, comments, and related editor surfaces). They are not owners. They cannot invite people, change roles, or open Admin → Threaded API Tokens.
Expiry (optional) You can set a date when you create or mint a token. If you leave expiry off, the secret works until someone revokes it.
This page is not Google service-account JSON on Admin → Integrations, and it is not Threaded MCP sign-in. Those are different credentials for different jobs.
#How It Works
#Opening Threaded API Tokens
Owners open Admin → Threaded API Tokens. The page is hidden unless this capability is enabled for the organization. Editors and operators who open the URL are sent back to Organization Info.
Turning the capability off hides this page. Existing secrets keep working until they expire or you revoke them. Revoke is the kill switch—not the feature flag.
#Creating a token
- Click Create API token.
- Enter a Name that you will recognize later.
- Optionally check Set an expiration date and choose when the secret should stop working.
- Click Create & mint token.
- Copy the secret immediately. Close the dialog only after it is stored.
The first secret is minted with the named token. You can mint additional secrets later from the same row.
#Using a token
Send the secret as a Bearer token (not the human Token scheme):
Authorization: Bearer thr_sat_…
The Threaded CLI accepts the same secret:
threaded auth login --service-token 'thr_sat_…' --organization '<org-uuid>'You can also set THREADED_SERVICE_TOKEN and THREADED_ORGANIZATION. The CLI requires an organization UUID because machine credentials are not listed by auth orgs.
#Minting, expiring, and revoking
Expand a name to see each secret’s prefix, last used time, expiry, and status (Active, Expired, or Revoked).
- Mint token creates another secret for the same name. Use this when you rotate: mint the new secret, update CI, then revoke the old one.
- Revoke immediately rejects that secret. There is no undo.
- Deleting the named token revokes every secret under it.
There is no automatic rotation wizard and no per-token access picker yet. Every customer-minted secret has the same editor-level grant. If a secret leaks, revoke it and mint a replacement.
#What a token can and cannot do
Can
- Read and edit organization work with editor-equivalent access
- Authenticate the CLI and HTTPS clients that send
Bearer thr_sat_… - Keep working if this admin page is later hidden (until they expire or you revoke them)
Cannot
- Manage members, owners, or API tokens
- Use the AI Assistant or hosted MCP as a human
- Recover a plaintext secret after the create dialog closes
- Impersonate a specific person or appear in the members list
Internal Threaded jobs may use a hidden scheduled-jobs principal. You will not see that row here, and you cannot mint or revoke it.
#Why This Matters
Machine credentials let process and platform teams run CI, syncs, and the CLI without borrowing a person’s login. Naming each token, copying the secret once, setting expiry when you want a deadline, and revoking on leak or offboarding keeps automation durable without widening owner access.