A valid request URL is required to generate request examples{
"keys": [
{
"apiKeyId": "<string>",
"keyId": "<string>",
"name": "<string>",
"scopes": [
"devices:read"
],
"deviceIds": [
"<string>"
],
"createdBy": "<string>",
"createdAt": "2023-11-07T05:31:56Z",
"expiresAt": "2023-11-07T05:31:56Z",
"revokedAt": "2023-11-07T05:31:56Z",
"lastUsedAt": "2023-11-07T05:31:56Z",
"rotatedFrom": "<string>"
}
],
"nextBefore": "<string>"
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}List the org's keys
Your org’s keys, newest first, one page at a time. Secrets are not stored in recoverable form and are never in this response. lastUsedAt is written off the request path, so it can lag slightly behind the last real use, which is worth knowing before you read a quiet key as unused.
PAGING. A full page carries nextBefore; send it back as before to get the next (older) page, and keep going until it is absent. Its absence is how paging ends, and it is the only reliable signal: a page that happens to be exactly full is not the end. This listing previously answered a bare array truncated at 200 rows with no cursor and no flag, so an org at the ceiling and an org far past it were indistinguishable.
WHO MAY READ IT. Any signed-in principal in the org, of either role. An ADMIN receives the full summary. A MEMBER receives the same keys, in the same order, with the same cursor, but a narrower projection: what a key IS (its ids, name, scopes, device narrowing, validity window and who created it) is returned, and how it has been USED is not, so lastUsedAt and rotatedFrom are withheld. A member can therefore see that their org has keys, match one they hold by its keyId to read why it does not work, and tell which rows are theirs to manage, without being handed the fields that rank an org’s credentials by how useful one would be to take away.
createdBy is an id and not a name; resolve it through your own directory. It is in the member projection because a member may manage the keys they created and would otherwise have no way to tell which those are.
An API key cannot read this listing at all, whatever the role of whoever minted it.
Hosted deployments only. A local checkout does not mount this route, so calling it there is a 404.
A valid request URL is required to generate request examples{
"keys": [
{
"apiKeyId": "<string>",
"keyId": "<string>",
"name": "<string>",
"scopes": [
"devices:read"
],
"deviceIds": [
"<string>"
],
"createdBy": "<string>",
"createdAt": "2023-11-07T05:31:56Z",
"expiresAt": "2023-11-07T05:31:56Z",
"revokedAt": "2023-11-07T05:31:56Z",
"lastUsedAt": "2023-11-07T05:31:56Z",
"rotatedFrom": "<string>"
}
],
"nextBefore": "<string>"
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}Authorizations
The control surface credential. Send Authorization: Bearer <token>.
Two kinds of token are accepted and they are told apart by shape, not by a separate header. A token beginning pbk_ is an org scoped API key, whose public half and secret half are generated together and of which only a hash of the secret is ever stored; anything else is treated as an OAuth 2.1 access token and verified against the authorization server's keys.
Both resolve to the same context: an org, a principal and a set of scopes. Nothing downstream branches on which channel you used, with one deliberate exception, key management, which requires a signed-in person so that a key can never mint another key.
Scopes are enforced when MCP tools are REGISTERED rather than when they are called, so a tool your credential cannot use is absent from tools/list rather than refused mid gesture.
Query Parameters
How many keys to return, 1 to 200. A larger value is refused, not shortened, so a caller is never left believing they received everything they asked for.
1 <= x <= 200Opaque cursor from a previous page's nextBefore. Returns only keys older than it. Treat it as opaque: its form is not part of this contract. An empty value is refused rather than read as no cursor, because that reads back as an org with no keys.
Response
A page of the org's keys.
A page of API keys, newest first.