List users
Use limit<=100 — limit is validated, and a value above 100 (or below 1) returns a clean 400 validation error ({"code": "validation_error", "message": "Invalid query parameters", ...}); the same cap applies to GET /v1/virtual-accounts and ALL list endpoints. Pass include_eligibility=true to also include capabilities.requested_banks and eligible_products on every row, identical in shape to GET /v1/users/{user_id} — omitted by default to keep the response light for callers that don’t need them.
Authorizations
Access token from POST /auth (the data.access_token value).
API key issued by Kira. Required on every request, including /auth.
Headers
Optional. The date-versioned API version to apply for this request (e.g. 2026-04-14). When sent it always wins, even over your pinned account default. When omitted, the API uses your account's pinned version if set, otherwise a baseline default.
"2026-04-14"
Query Parameters
Maximum number of users to return (1-100).
1 <= x <= 100Number of users to skip for pagination.
x >= 0Filter by user status.
CREATED, VERIFYING, VERIFIED, REJECTED, REVIEW, ACTIVE, INACTIVE, SUSPENDED Filter by user type.
individual, business Substring match against the user's email.
Filter by verification status. Accepts the same lowercase values the response's verification_status field carries.
unverified, started, in_review, verified, rejected, needs_action Return users created at or after this ISO 8601 date-time.
Return users created at or before this ISO 8601 date-time.
Stripe-style metadata filter — ?metadata[key]=value deep-object form. Each key must be 1-40 characters and must not contain [ or ]. Multiple keys are AND-ed.
When true, each row also includes capabilities.requested_banks and eligible_products. Omitted (false) by default — computing eligibility for every row costs a lookup plus in-memory evaluation per subclient, so it's opt-in rather than always paid by every list caller.