Skip to main content
GET
Read a person

Authorizations

Authorization
string
header
required

Bearer token authentication. Pass your API key as Authorization: Bearer sk_.... See Authentication for keys, scopes, and sandbox vs production.

Path Parameters

account_id
string
required

The account to act on. It must be one of your own accounts; any other ID returns 404.

person_id
string
required

The person on that account.

Response

The person.

id
string

The person's identifier, prefixed per_. Requirement keys are anchored to it, so persons.per_3a91c0d7.id_document names exactly who owes a document.

Example:

"per_3a91c0d7"

first_name
string | null

The person's given name as recorded, or null when it has not been supplied yet. It is the name their identity document is checked against.

Example:

"Ada"

last_name
string | null

The person's family name as recorded, or null when it has not been supplied yet. It is checked against the identity document alongside first_name.

Example:

"Obi"

dob
string | null

ISO-8601 date, YYYY-MM-DD.

Example:

"1990-04-12"

address
object | null

The person's residential address, carrying the line1, city, state, postal_code and country keys that were written, or null when no address has been supplied. It is stored whole, so a later write replaces it rather than merging into it.

phone
string | null

The contact number recorded for this person, returned exactly as it was sent, or null when none has been supplied.

Example:

"+2348012345678"

email
string | null

The email address recorded for this person, or null when none has been supplied. It belongs to the person, not to the account, so it differs from the account's contact_email.

Example:

"ada@example.com"

id_number_provided
boolean

true when a government ID number is held for this person, false when none has been supplied. The number itself is write-only and never returned, so this flag is how you tell whether you still need to collect one.

Example:

true

relationship
object

Role flags. One person is commonly several of these at once, which is why they are flags on one person rather than separate collections.

verification
object

What has been established about this person. How it was established is not reported.

created_at
string<date-time>

When the person was added to the account, ISO 8601 in UTC.

Example:

"2026-08-10T09:31:12.000Z"

updated_at
string<date-time>

When the person record last changed, ISO 8601 in UTC. A verification outcome we record moves it as well as your own writes, so do not read it as the time of your last edit.

Example:

"2026-08-11T14:05:40.219Z"