Skip to main content
The values each enumerated field on a user takes. Check it when you are branching on a field’s value or building a form that has to offer the right options.

status

The user’s lifecycle status. It comes back on every user object, and you can filter a listing by it.
Compare status values case-insensitively. User statuses are uppercase everywhere — see State machines.

Legacy values

These three predate the current verification flow. They are still accepted as a filter and can still be returned by users created before it, so handle them if you read historical data — but no new user reaches them.

type

Whether the user is a company or a person. It comes back on every user object, and you can filter a listing by it.

verification_status

The result of the user’s identity or business check. It comes back on every user object, and you can filter a listing by it.

verification_mode

How a business gets verified. You choose this when you create it, and it comes back on every read.

business_industry

The industries a business works in, as NAICS subsector slugs. A business takes an array of them.

business_type

The legal structure of a business.

Older spellings

These 10 are still accepted and mean the value beside them. Send the canonical value instead — these are kept for integrations written before it existed.

language

The locale for the hosted verification form. It only matters when verification_mode is verification_link.

account_purpose

What the account will be used for.
A business accepts these.A person accepts these.

source_of_funds

Where the money comes from.
A business accepts these.A person accepts these.

expected_monthly_volume

How much is expected to move in a month, as a bucket.
A business accepts these.A person accepts these.

expected_transaction_count

How many payments are expected in a month, as a bucket.
A business accepts these.A person accepts these.

identifying_information types

What kind of record you are sending. The kind decides where its value goes: an identifier goes in number, a file goes in documents[].
Government photo IDs. Send the number in number and the images in documents[]. Every one of these needs a front and a back, except passport and visa.Tax and identity numbers. Send the value in number. No file needed. tax_id is accepted on the business itself, not on an associated person.Documents. Attach the file in documents[].Business documents. Also attached in documents[], and only valid on a business.

documents types

What a file is within the record it belongs to. Three of these are the images of an identity document; the rest are supporting paperwork.
Which of these a business needs depends on the product you are opening. Read missing_fields instead of uploading the whole set.

liveness subject

Who a liveness link is for. A business gets one link per beneficial owner, so you need this to route them.

liveness code

Why a liveness link could not be minted. It comes back on the 422, and it is what to branch on.
Whether the note in verification_link_error asks anything of you. The two always arrive together.

unsupported_reason

Why a product is closed to a user when no data can change it. It replaces that product’s missing_fields — the two never appear together.

employment_status

What the person does for a living.