Skip to main content
GET
List User Pats
User PATs (pat_…) are Logto-native personal access tokens with no local database row at all — see Authentication for how they differ from organization API keys. They’re addressed by name, not id, and names must be unique per user. None of the other seven PAT/key management endpoints require a dedicated manage scope — a PAT or key is inherently scoped to the caller’s own identity, so any authenticated request can call them. Scoped to the caller’s own Logto user id — organization context is irrelevant here, since user PATs aren’t org-bound. This reads straight from Logto’s personal-access-token list for the caller, filtered to names carrying the pat_ prefix this app uses internally (org API keys are backed by Logto PATs too, but named differently, so they don’t leak into this list).
The value field below is whatever Logto’s Management API returns for each token on this call. Because user PATs are entirely Logto-managed (no local hash-and-discard step like ak_ keys), this reference cannot promise it’s a one-time reveal the way pat_key on org keys is — treat any value you receive as sensitive and avoid depending on repeat calls continuing to return it.

Auth

Requires pats:read, which every default role carries. This reads the caller’s own Logto personal access tokens, keyed on the token’s subject — there is no way to read another member’s, not even as an org admin. No active organization is needed either: user PATs aren’t org-bound.

Response

200 OK — a bare JSON array.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Response

200 - application/json

Successful Response

name
string
required
value
string
required
created_at
string | null
expires_at
string | null