Update a user
Changes an existing user. Only the fields you send are written — everything else is left alone.
Use it to fill in what missing_fields still asks for.
A missing file works differently: sending other fields will not clear it. You have to send the file itself again in identifying_information[].documents[].
Touching a field the user’s category needs for verification starts the check again and the response says requires_reverification: true. A successful change emits a user.updated webhook (see Webhooks).
Headers
Version applied to this request. It wins over your account's pinned version — see Versioning.
"2026-04-14"
Path Parameters
The id of the user to change. It must be a UUID.
Body
Which banks this user plans to use. This records intent only — authorizing an account for a bank is separate.
How the user gets verified.
See User values for the accepted values.
automatic, verification_link The person's given name.
1The person's middle name.
The person's family name.
1Date of birth, YYYY-MM-DD. Must be 18+.
^\d{4}-\d{2}-\d{2}$ISO alpha-3 nationality.
3The person's gender.
male, female, other Exact string, e.g. U.S. Citizen, Permanent U.S. Resident, Non-Resident of U.S.
The registered legal name of the business.
1Backward-compatible alias for business_legal_name.
Accepted here, but not returned in the user object — do not expect to read it back.
1The name the business trades under, when it differs from its legal name.
The legal structure of the business.
See User values for the accepted values.
Accepted here, but not returned in the user object — do not expect to read it back.
The industries the business works in, as NAICS subsector slugs — telecommunications, real_estate, construction_of_buildings.
See User values for the accepted values.
Accepted here, but not returned in the user object — do not expect to read it back.
Accepted here, but not returned in the user object — do not expect to read it back.
The business's website.
The date the business was formed, YYYY-MM-DD.
^\d{4}-\d{2}-\d{2}$The state or province the business was formed in.
The country the business was formed in, as an ISO alpha-3 code.
3Given name of the person representing the business.
Family name of the person representing the business.
The representative's role in the business.
Representative date of birth, YYYY-MM-DD. On create this field is representative_date_of_birth.
^\d{4}-\d{2}-\d{2}$The representative's US Social Security number.
The user's email address.
E.164 format, e.g. +14155551234.
The person's primary identity document.
The number on that document.
The country that issued it, as an ISO alpha-3 code.
3Street address.
Apartment, suite or unit.
City.
State or province. For the USA, the 2-letter state code.
ZIP or postal code.
ISO alpha-3 country.
3Nested residential address (V1). You may instead use the flat address_* fields.
US individuals only — do NOT send for non-US individuals.
Brazil individual tax ID.
Mexico individual ID.
Mexico tax ID.
US businesses only — do NOT send for non-US businesses.
Brazil business tax ID.
Generic international tax ID.
Which kind of tax identifier tax_id carries.
Where the money comes from.
See User values for the accepted values.
Accepted here, but not returned in the user object — do not expect to read it back.
What the account will be used for.
See User values for the accepted values.
Accepted here, but not returned in the user object — do not expect to read it back.
Free-form. Prefer expected_monthly_volume + expected_transaction_count.
How much is expected to move in a month.
See User values for the accepted values.
less_than_10000, 10000_to_49999, 50000_to_199999, 200000_to_999999, 1000000_or_more, less_than_50000, 50000_to_100000, 100000_to_500000, 500000_to_1000000, 1000000_to_5000000, 5000000_to_10000000, more_than_10000000 How many payments are expected in a month.
See User values for the accepted values.
1_to_10, 11_to_50, 51_to_200, more_than_200, less_than_10, 10_to_25, 26_to_50, 51_to_100, 101_to_500, more_than_500 What the person does for a living.
See User values for the accepted values.
employed, self_employed, unemployed, retired, student The person's occupation code.
Send only when employment_status = employed.
Where the person's income comes from.
Whether this person is, or has been, a politically exposed person.
false is a real answer — leaving the field out is not the same thing.
A KYB attestation: whether the business operates in a high-risk industry.
Yes, No A KYB attestation: whether the business is a non-bank financial institution or a virtual-asset service provider.
Yes, No A KYB attestation: whether the business has relevant legal history.
Yes, No The countries the user expects to transact with, as ISO 3166-1 codes.
When it is absent the gap is reported in missing_fields — Kira never guesses a market you did not declare.
1Terms-of-service version the user accepted.
How the corporation is taxed.
How the limited liability company is taxed.
Free-text entity type for non-US businesses.
The kind of government document being supplied.
Free-form string map. International users include has_us_bank_account / has_denied_bank_account as Yes/No (case-sensitive; lowercase is not accepted by ACT provisioning).
Tax IDs and government documents to add or replace. Each entry requires type and issuing_country.
UBOs and authorized signers (businesses). Merged by email. Note the phone field here is phone_number.
Legacy flat document array. Prefer identifying_information[].documents[].
A patch, not a replacement: keys shallow-merge, an empty-string value deletes that key, {} clears all. ≤ 50 keys; key 1–40 chars, no [ or ].
Response
The change was applied. updated_fields says what was written.
The user after the change, plus what the change did.
User UUID.
Whether the user is a company or a person.
Available options: business, individual.
See User values for what each one means.
Email address.
Where the user sits in its lifecycle.
Available options: CREATED, VERIFYING, REVIEW, VERIFIED, REJECTED, plus the legacy ACTIVE, INACTIVE and SUSPENDED.
See User values for what each one means.
The result of the user's identity or business check.
Available options: unverified, started, in_review, verified, rejected, needs_action.
See User values for what each one means.
Creation timestamp (ISO 8601).
Last-update timestamp (ISO 8601).
automatic or verification_link.
Hosted KYC URL — present only in verification_link mode.
A plain-text note about something the request could not finish — the hosted verification link, or a move of this user to a different bank.
The wording can change, so branch on verification_link_error_severity, never on this string.
Whether the note in verification_link_error asks anything of you.
See User values for what each value means.
deferred, failed The key-value pairs you stored on this user.
If your account has default metadata configured, it is merged in when the user is created and your own keys win on a 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).
The person's nationality, as an ISO alpha-3 country code — USA, MEX.
Where the person was born, as an ISO alpha-3 country code. Absent when it was never set.
male, female, or other, when provided.
The person's address, as a nested object.
Country the business was formed in, as an ISO alpha-3 code.
The registered legal name of the business.
The registered, legal address of the business.
Whether this change re-triggered the identity check. It turns true when you touch a field the user's category needs for verification.
Users on a hosted form are never re-queued.
Whether verification started as a result of this change.
The fields this call wrote, in the order you sent them. Use it to confirm the API read what you meant.
What this user can already use, product by product.
Each entry carries eligible, and when that is false, the reason why:
missing_fields— data is missing. Send it, and the product turns eligible once the user passes verification.unsupported_reason— nothing you send will change the answer.
A product stays eligible: false until the user reaches the status that product asks for, which is usually VERIFIED.
The gaps that remain, grouped by product code, plus a general key holding every token once.
A product with nothing outstanding is left out of the map, so it can come back with only general, or empty.
The user's identity or registration records. null when none are stored, and absent on users whose verification runs through a hosted link.
The people tied to a business. null for a person, and absent on users whose verification runs through a hosted link.
Non-fatal problems with the documents you sent. A document that fails to upload shows up here and does not fail the call. Absent when there are none.