List API keys
Answers { data, keys, nextCursor }: data is the field the checkout and buyer-profile lists also use and the one to read, keys is the same array under its original name, and nextCursor is always null because this collection is not paged. Newest first. Revoked keys are included, with revokedAt set — filter client-side if you only want active ones.
Listing never returns a secret. keyPrefix is the most a list can show.
Requires the api-keys.read scope.
A subject-bound key cannot call this: the key list is a tenant-wide fact, and a credential acting for one end user must not be able to enumerate its siblings. 403.
Authorizations
Authorization: Bearer ck_test_… or ck_live_…. There is no other auth scheme — no query-string keys, no request signing, no OAuth.
Response
Every key on the tenant, newest first, revoked ones included. Not paged.
The collection. Read this one — it is the field the checkout and buyer-profile lists answer with too. (GET /v1/buyer-sessions is the one list route that has not converged: it answers { sessions, vaultEnabled }.)
The same array under the field's original name, kept because existing callers read it. Identical contents; prefer data in new code.
Always null here — the collection is small and tenant-bounded, so there is nothing to page. Present so a generic list client needs no special case.