Manage an Individual

Read and update a shared person record; the change applies everywhere the Individual is linked.

An Individual is shared, so a change to the person applies everywhere they're linked. Read a person back to confirm their details and verification status, and update them in place when something changes. For the full field list, see Create an individual.

Common use cases

  • Read a person's details and verification status.
  • Update a person's contact or identity details in one place.
  • Reuse a person across another business by their id.
🚧

PENDING-PUBLISH

The boarding API Reference is pending publication; the ref: targets on this page are placeholders. Replace each with the real boarding-spec operationId once the boarding reference ships.


Scenarios

An Individual is standalone and shared, so read and update happen on the person's own resource, and any change flows to every business the person is linked to.

Before you begin (all scenarios)

  • You have the individualId (or the externalId you set on create).

Scenario 1: Read an individual

Read a person by their id. Make a GET request to /v1/individuals/{individualId} (or resolve by your own reference with ?externalId=).

curl https://sandbox-api.prioritycommerce.com/v1/individuals/{individualId} \
  -H "x-api-key: <your-key>"

An Individual reports its verification status as it moves IN_PROGRESS → VERIFIED. See Status lifecycle.

Scenario 2: Update an individual

Update a person's details in place, sending only the fields you're changing. Make a PATCH request to /v1/individuals/{individualId}.

curl -X PATCH https://sandbox-api.prioritycommerce.com/v1/individuals/{individualId} \
  -H "x-api-key: <your-key>" \
  -H "Content-Type: application/json" \
  -d '{ "email": "[email protected]", "phone": "+15125550199" }'

Because an Individual is shared, an update applies to every business the person is linked to as an owner or signatory.

🚧

PENDING-PUBLISH

The exact management contract for a standalone Individual (list, delete, and whether an identity change triggers re-verification) is not confirmable while the boarding spec is out of reference/. Confirm the available operations and re-verification behavior before publish.


Statuses

An Individual moves IN_PROGRESS → VERIFIED, and re-reading the person shows the current status. Re-verification after an identity change is pending confirmation (see the note above). See Status lifecycle and Underwriting exceptions.


Sandbox testing

Use the sandbox to read and update people before going live.

ScenarioTest dataExpected result
Read a personA valid individualId200 OK with the person and their status
Update contactPATCH with email200 OK; only that field changes
Shared updateLink the person to two businesses, then updateThe change is reflected on both

Best practices

PracticeDescription
Update in one placeChange the shared Individual once; the update flows to every linked business.
Read back after a changeConfirm the update and the current verification status.
Resolve by externalIdLook the person up by your own reference when you don't have the ind_ id to hand.

Next steps

See also



Did this page help you?
.readme-logo { display: none !important; }