Skip to main content
A person (per_...) is a natural person (human) or legal person (company, trust, other entity). Persons are standalone until an onboarding application referencing them is approved. Every person is built from claims, typed data points capturing identity, residence, ownership, PEP status, and so on. Every POST /persons must include at least the mandatory claim set for its person_type: Omitting any of these returns 400 invalid_request with detail <person_type> persons require claim types [...]; missing: [...]. You can include additional claims in the same request (and usually will, to round out the person’s profile). person_type determines which claim types are acceptable. operating_address is also a legal-person claim. You only add it when the legal owner’s registered_address has operating_address_is_same set to false; see conditional requirements. Legal persons declare counterparties (directors, shareholders, UBOs, trustees, signatories) via a relationships claim. Related persons must already exist. Claim types are enforced against person_type: mismatches on POST /persons or POST /persons/{person_id}/claims return 400 invalid_request. See the claim type reference.

Creating a person

POST /persons with person_type and a non-empty claims array. Creation is atomic: if any claim fails validation, nothing is persisted.

Response

A successful request returns 201 Created:
Persons don’t have their own status; lifecycle lives on claims. See lifecycle.
POST /persons doesn’t de-duplicate retries. Record the returned id and reuse it on retries.

Retrieving a person

Use GET /persons/{id} to fetch the person record. Claims aren’t included; list them separately.
Use GET /persons/{person_id}/claims to list the person’s claims, filtered by claim_type or status. By default you get every row for the person (current and historical) newest-first. Pass include_history=false to collapse to just the current rows (active + in_flight) per type. See listing and retrieving claims.

Authorities

When an application referencing a person is approved, that person becomes an authority on the resulting customer and accounts. List authorities per person with GET /persons/{id}/authorities. Create one person for the legal entity and one for every director, shareholder, UBO, trustee, settlor, or authorised signatory. Then add a relationships claim on the legal person.
Related persons must already exist; an unknown related_person ID fails the request with 400 and nothing is persisted. See claim types for the full relationships schema.