Skip to main content
Settings → API tokens issues credentials for reading Pipefort from somewhere that is not a browser. Admins only.

​
What a token can do

A token acts as the member who created it. It carries no permissions of its own, which means nobody can mint a token more powerful than themselves — and it inherits their role, so a token made by a non-admin cannot reach an admin-only endpoint.
A token can only read. Every request that is not a GET is refused, and so is the one GET that changes state — /api/github/callback, which links a GitHub App installation. Without that second rule a “read-only” credential could have attached an installation to its own organisation and granted itself repository access.
It also cannot outlive its creator’s membership. Removing a member revokes their tokens, and every request independently re-checks that the creator is still a member — so a token that somehow escaped revocation still stops working.

​
The value is shown once

Only a SHA-256 of the token is stored. It is displayed at creation and never again, by the page or by anyone else, because there is nothing left to display it from. If you lose it, revoke it and create another. The listing shows a hint (pf_625d53d4…) instead — the public half, which identifies the row and cannot be used to reconstruct the token.

​
Choosing an expiry

30 days, 90 days, a year, or never. “Never” is offered and labelled rather than being a silent default: a credential with no end date is a decision, and the page says what it means — the token stays valid until someone revokes it or its creator leaves.

​
Last used

The column that makes the page worth opening. Never used and last used in March are different words, not a shared blank cell, because only one of them means “safe to revoke without asking anyone”. Use is recorded to the minute. A busy caller does not turn every read into a write, and no finer resolution helps answer the only question the column exists for.

​
Revoking

Immediate and permanent. A revoked token stays listed, struck through, with its own history — so “this existed, it was used until the 12th, and it is now dead” remains readable rather than vanishing. Creating and revoking a token are both recorded in the audit log.

​
Every rejection looks the same

An unknown token, a wrong one, a revoked one and an expired one all return the same 401 with the same body. A client that could tell them apart could use the difference to work out which tokens exist.