API tokens (PRO)
Keys for outside clients: a Nuxt front end, a mobile app, an exchange with an accounting system. The client sends the token in a header, the route checks the scopes.
PageBlocks → Constructor → API tokens.
Authorization: Bearer pb_1a2b3c4d…A token
| Setting | What it does |
|---|---|
| Name | So you know whose it is. "Nuxt front end", "1C exchange" |
| Scopes | One per line |
| Expires at | Empty means never |
| On behalf of | Requests run as this MODX user. Empty means anonymous |
| Active | A disabled token stops working without being deleted |
Scopes
A route demands a particular scope, and the token either has it or does not:
| Written as | What it grants |
|---|---|
cargo.read | Exactly that scope |
cargo.* | The whole cargo group |
* | Everything |
| empty | Only routes that demand no scope |
A token with no scopes at all is shown in red in the list — that is almost always an oversight rather than a plan.
The token is shown once
Nobody can show it to you a second time
Only a hash is kept on the server. The list shows the start of the token — enough to recognise the right one, not enough to use it. Lost it? Reissue.
Reissuing hands out a new token and kills the old one immediately: every client still using it gets a 401. That is how you revoke a leaked key.
Who called, and when
The list shows the date of the last request and the address it came from. A token unused for six months is a candidate for switching off — and now you can see that rather than guess.
What is actually served over the API and how to publish it is in REST API; the generated description lives in the API documentation tab.