Get a user
Returns the full user resource. Eligibility: eligible_products[] is populated immediately on create and on every GET — even before verification. Each product carries eligible (false until the user reaches the product’s minimum status, e.g. VERIFIED) and its own missing_fields; verification flips eligible to true and clears missing_fields rather than populating the array. Gate your flow on status (verification_status is advisory and can contradict it). Bank intent: capabilities.requested_banks is always present, including as [] when nothing is declared — never omitted.
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-06-01"
Path Parameters
User UUID.
Response
Success.
User UUID.
individual or business.
individual, business Email address.
Lifecycle status: CREATED, VERIFYING, REVIEW, VERIFIED, or REJECTED. Gate product readiness on this, not on verification_status.
Creation timestamp (ISO 8601).
Last-update timestamp (ISO 8601).
KYC/KYB status: unverified, started, in_review, verified, rejected, or needs_action.
unverified, started, in_review, verified, rejected, needs_action automatic or verification_link.
Hosted KYC URL — present only in verification_link mode.
Populated if hosted-link generation failed, or on PUT /v1/users/{user_id} when a bank-migration triggered by the request was deferred or failed. Freeform, human-readable text — branch on verification_link_error_severity, not this string.
Machine-readable companion to verification_link_error, present only alongside it on the PUT /v1/users/{user_id} response. deferred means nothing is wrong — the triggered bank migration is waiting on something expected or was correctly skipped by a business rule. failed means the migration hit a genuine problem.
deferred, failed Your key-value pairs, plus any client-level default metadata configured for your account (merged at create time; your request keys win on conflict).
Given name (individual users).
Family name (individual users).
Middle name (individual users), when provided.
Contact phone in E.164 form (e.g. +525512345678).
Date of birth, YYYY-MM-DD (individual users).
Nationality as an ISO alpha-3 country code (e.g. MEX, USA). Users use alpha-3; recipients use alpha-2 — map accordingly.
male, female, or other, when provided.
male, female, other The individual's address. The response renests and renames the flat create-request fields: address_street → street_line_1, address_state → subdivision, address_zip_code → postal_code, address_city → city, address_country → country. Parse this nested shape — the flat address_* request fields do not round-trip.
Write-only in practice: accepted on create/update but currently NOT returned by GET — do not depend on reading it back.
Write-only in practice: accepted on create/update but currently NOT returned by GET — do not depend on reading it back.
Per-product eligibility, computed from the user's supplied fields against the product matrix — present on the create response and on the single-resource GET (GET /v1/users/{user_id}), even before verification. On the list (GET /v1/users), present only when the request passed include_eligibility=true; omitted otherwise. Each product carries eligible (false until the user reaches the product's minimum status, e.g. VERIFIED) and its own missing_fields. Verification flips eligible to true and clears missing_fields; it does not populate the array. A product that is eligible: false for a reason no field can clear carries unsupported_reason instead of missing_fields — verification will not flip it.
Map of product_code → outstanding field tokens, plus a general key with the deduplicated union across products. It is populated before verification too; the sole exception is that this top-level aggregate is omitted on the create response for verification_link-mode users or when there are zero gaps.
Per-subclient bank intent — which banks this subclient has declared it needs. Always present on GET /v1/users/{id}, including { "requested_banks": [] } when nothing is declared — never omitted there. On the list (GET /v1/users), present only when the request passed include_eligibility=true; omitted otherwise.