Wambesha

Accountkeys

GET/v1/account/keys

Calls quota only

Every API key on your account - name, prefix, last four, environment, restrictions and last use. Never the secret. Never charged.

Parameters

This endpoint takes no parameters.

Response fields

itemsApiKeySummary[]
maxKeysinteger · int64nullable
How many LIVE keys this account's plan permits, or null for unbounded (Enterprise). REQUIRED and NULLABLE — the two are not alternatives. PublicApiKeyListResponse is @JsonInclude(ALWAYS), so this key is on the wire on every response; what varies is whether its value is a number or null. Declaring it required expresses "always present", and type: [integer, 'null'] expresses "may be null". Leaving it OUT of required was a real defect for a day: openapi-typescript then emits maxKeys?: number | null, i.e. possibly ABSENT, which is a state the runtime cannot produce - and a client helper typed (maxKeys: number | null) stops compiling against its own API. This is an ACCOUNT-scoped schema, and the reasoning above does not generalise to the community pillar. .claude/rules/validation-patterns.md records the house convention there: a nullable field stays OUT of required, and the CommunityPost.editableUntil precedent is a NON-NULL field, so it is not the parallel it looks like. CommunityStatementOfReasons in this same change correctly leaves six nullable fields out of required on that convention. Do not read this block as licence to add them. A client that treats a missing value as 0 tells an Enterprise customer they may create no keys. Pair it with liveCount to decide whether to offer the create form or refuse it.
liveCountinteger · int64
How many keys are currently live, i.e. counted against maxKeys. Revoked keys appear in items but are not counted here, so liveCount is deliberately not items.length.

Response headers

X-Request-ID
The id of this request, on every response - success or error. Quote it to support: it is how we find your request in our logs. An X-Request-ID you send is honoured and echoed back, so you can use your own; otherwise we generate one. /v1 error bodies carry no trace id of their own.
X-Quota-Reset
RFC 3339 instant at which the billing period rolls. Present on every response to a request whose key was metered - every 2xx, every error a handler returned, and the quota 429. Absent on a refusal that happens before metering: a missing or unknown key (401), a restricted key or a plan that does not carry the endpoint (403), a public demo-key gate refusal, and the pre-authentication flood throttle.
X-Calls-Remaining
Requests left in the period after this one, never below 0. Present whenever X-Quota-Reset is (see there for when a response carries no quota headers).
X-Verifications-Remaining
How many verifications you can still make before a limit stops you. The daily limit and the monthly allowance are counted separately; this is whichever of the two runs out first. Sent whenever X-Quota-Reset is.
X-Quota-Grace
true when THIS request fell inside the 10% grace band above a monthly ceiling. A grace request is served and is not billed; treat true as "back off now", not as headroom. Always true or false, never absent when the other quota headers are present.
Retry-After429
Seconds to wait before retrying. On every 429 - the quota hard stop, the public demo key's limits, and the pre-authentication flood throttle (which carries this header alone, because no key has been read yet).
X-Demo-Challenge-ModeDemo key only
Sent only on responses to the public demo key. The value interactive asks the documentation page to show the visible verification widget - it is sent once a browser has made more than five runs in ten minutes or has received a 429. The page then repeats the header, X-Demo-Challenge-Mode: interactive, on its next request, with the widget's token in X-Demo-Challenge. Requests made with your own key never receive it.

Errors

Details

Every key on the account, newest first, with its scopes, IP allowlist and referrer restriction.

Revoked keys are included. A customer investigating a leak needs to see the key that leaked, and its usage history is retained for exactly that.

No secret is ever returned here, and none can be: the store holds a SHA-256 hash, so there is no code path that could produce the original value.

Creating, renaming and revoking are NOT on this key-authenticated surface - they need a session, at /api/v1/developer/keys. That split is deliberate: a customer who has just revoked their only key would otherwise have no way to mint a replacement.

Try it

Loading the demo key…

curl "https://api.wambesha.com/v1/account/keys" \
  -H "Authorization: Bearer YOUR_API_KEY"

Example

{
  "items": [
    {
      "id": "5c1d7e00-0c17-4d0c-9c17-00000000cafe",
      "name": "cycle17 docs examples",
      "prefix": "wba_test_",
      "lastFour": "a048",
      "environment": "TEST",
      "createdAt": "2026-09-27T16:21:03Z",
      "lastUsedAt": "2026-09-27T16:21:04Z",
      "expiresAt": null,
      "revokedAt": null,
      "rotatedAt": null,
      "rotationGraceUntil": null,
      "scopes": [],
      "ipAllowlist": [],
      "referrerAllowlist": []
    }
  ],
  "maxKeys": 20,
  "liveCount": 1
}