Read the caller's own identity and scopes
const url = 'https://example.com/v1/me';const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://example.com/v1/me \ --header 'Authorization: Bearer <token>'Echoes the identity the gateway derived from the caller’s token: the tenant it will scope every request to, the acting user, and the effective OAuth scopes. Nothing here is new authority — every field comes from the validated token the caller presented — and no lookup is performed, so no other tenant’s data can reach the response.
It exists for clients that legitimately cannot read their own token: a console whose backend-for-frontend holds the bearer server-side has no other way to name the tenant it is administering, or to know whether the operator may read invocation bodies.
Authorizations
Section titled “Authorizations”Responses
Section titled “Responses”The caller’s identity.
The caller’s own identity, derived from its validated token.
object
The tenant every request from this caller is scoped to.
The acting user (the token’s subject claim).
Effective OAuth scopes. Empty when the token carries none.
Whether the token carries invocations:read_body. Named rather than left to be re-derived from scopes, because it gates one specific high-risk surface and a client that string-matches a scope name will eventually match the wrong one.
Examplegenerated
{ "tenant_id": "example", "user_id": "example", "scopes": [ "example" ], "can_read_invocation_bodies": true}Missing or invalid bearer token, or the token’s tenant/user claims are absent. No body.