A valid request URL is required to generate request examples{
"id": "<string>",
"keyId": "<string>",
"name": "<string>",
"orgId": "<string>",
"scopes": [
"devices:read"
],
"deviceIds": [
"<string>"
],
"createdAt": "2023-11-07T05:31:56Z",
"expiresAt": "2023-11-07T05:31:56Z"
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}Describe the calling key
The API key making this request, about itself: its id, name, organisation, scopes and expiry. This is what phonebase whoami shows. Only an API key may call it; a signed-in person has no current key and is refused 403. It never returns the secret.
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{
"id": "<string>",
"keyId": "<string>",
"name": "<string>",
"orgId": "<string>",
"scopes": [
"devices:read"
],
"deviceIds": [
"<string>"
],
"createdAt": "2023-11-07T05:31:56Z",
"expiresAt": "2023-11-07T05:31:56Z"
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"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.
Response
The calling key.
The API key making the request, as it describes itself. Never the secret.
The key's own id, the apiKeyId a listing shows.
The public half of the token, the part before the secret.
The organisation this key acts for.
A granted scope.
devices:read, devices:act, devices:lease, runs:start, orders:place, apps:read, apps:write, apps:delete The device subset this key may see and address, or null for the whole org.