Your account can hold three kinds of credential. They are separate on purpose: each authenticates a different sort of caller against a different surface, and one can never be presented to another’s.
| Credential | Prefix | Managed at | For |
|---|---|---|---|
| API key | tmc_ |
Account → API keys | You, scripting your own content |
| Integration | tmci_ |
Account → Integrations | A game server or mod reporting to us |
| App token | — | Account → Sessions | The official desktop app |
API keys
An API key lets a script do what you could do in the browser.
- canRead / canWrite / canDelete
Which HTTP methods the key may use. A read-only key is the right default for anything that only fetches.
- scope
A
CONTENT-scoped key is pinned to one item. It answers for that item’s type and id and nothing else.- IP whitelist
Requests from other addresses are refused. An empty whitelist allows all addresses.
- Auth mode
Bearer (a secret sent on every request) or JWT (you hold an Ed25519 private key and send a short-lived signed assertion). Fixed for the life of the key.
A key can never exceed what its owner could do in the UI. Every write resolves to the same access check the edit form uses.
Live usage is shown on the page for both rate-limit windows, and every request — including rejected ones — is written to your audit log with its method, path, status, address and the item it touched.
Integrations
An integration is a credential for a program: a game server plugin or a game mod, reporting facts about one content item.
Each is bound to exactly one item and carries a set of scopes. A server-scoped credential may only touch things on that server; an app-scoped one only things for that app.
| Status | Means |
|---|---|
PENDING |
Created, never used. Authorises exactly like active — it exists so your list can distinguish “never connected” from “working”, which is the first thing anybody debugging a plugin wants to know |
ACTIVE |
In use |
INACTIVE |
Switched off by you. Reversible |
REVOKED |
Killed permanently |
Revoked means revoked
Revoking rotates the stored hash to a value nothing can produce. The token is dead as a property of the credential, not as a status somebody has to remember to check — flipping the row back will not bring it to life.
Revoke keeps the request log. Delete removes both.
There is a cap on how many integrations may exist against one item at a time (10 by default). Revoked ones do not count.
App tokens
The official app signs in through a device flow — you approve it in the browser, and it receives an access token and a refresh token. See App authentication.
App sessions appear under Account → Sessions alongside browser sessions and are revoked the same way.
Secrets are shown once
All three follow the same rule: the plaintext is shown once, at creation, and never again. Only a hash is stored. A lost token is replaced, not recovered.
For keys and integrations in JWT mode there is no secret at all — you hold the private key, we store only the public half, so a full dump of our database grants nothing. The private key is likewise shown once and is not recoverable.