Skip to main content
POST
Submit a customer update application

Authorizations

x-api-key
string
header
required

Headers

Idempotency-Key
string
required

Caller-generated unique key that lets the server safely replay this request. The cached response is returned for 5 minutes on any retry with the same key from the same API principal. Required on every state-changing money-moving or resource-creating POST.

Required string length: 1 - 128
Pattern: ^[A-Za-z0-9_.:-]{1,128}$

Path Parameters

customerId
string
required

Body

application/json
businessInfo
object

Business-level fields to update (e.g. legalName, tradeName, contactEmail, contactPhone, website, taxId). Inner shape mirrors the onboarding submit shape.

registeredAddress
object

Updated registered business address. Inner shape (e.g. addressLine1, city, state, postalCode, country); country accepts ISO 3166-1 alpha-2 or alpha-3.

operatingAddress
object

Updated operating address. Same shape as registeredAddress.

companyClassification
object

Updated legal-structure / industry classification. Inner shape resolved at submit by the requirements engine.

businessActivity
object

Updated operating-activity descriptors.

compliance
object

Updated compliance attestations.

regulatoryHistory
object

Updated regulatory / adverse-action history.

ownership
object

Updated beneficial-owner / controlling-person disclosure. Sending ownership.persons replaces the full owner set: to edit an existing owner, include its id (from a customer read) plus the fields you want to change; omit id to add a new owner (full identity required); owners not listed are removed.

Updated related-company disclosure.

certification
object

Updated legal certifications. Same mustEqual: true gating as onboarding.

documentIds
string[]

Customer-level document IDs from POST /v2/documents to attach to this update. Per-person documents go on ownership.persons[i].documentIds[].

Maximum array length: 100
Minimum string length: 1
Example:
clientReferenceId
string

Optional client-supplied identifier for the resulting customer-update application. Useful for reconciling the submission against an external system. 1-255 characters from A-Za-z, 0-9, underscore, hyphen, colon, and period — no spaces.

Pattern: ^[A-Za-z0-9_\-:.]{1,255}$
Example:

"ext-update-2026-05-14-001"

Response

The submitted customer-update application

id
string
required

Unique application identifier

Pattern: ^app_[0-9A-Za-z]{22}$
status
enum<string>
required

Current lifecycle status of the application

Available options:
pending,
processing,
approved,
rejected,
cancelled
Example:

"pending"

createdAt
string<date-time>
required

Timestamp when the application was created

Example:

"2026-01-15T09:30:00.000Z"

updatedAt
string<date-time>
required

Timestamp when the application was last modified

Example:

"2026-01-15T09:30:00.000Z"

type
enum<string>
required
Available options:
customer_onboarding
clientReferenceId
string

Client-provided identifier for cross-referencing. Omitted when the client did not supply one. 1-255 characters from A-Za-z, 0-9, underscore, hyphen, colon, and period — no spaces.

Pattern: ^[A-Za-z0-9_\-:.]{1,255}$
Example:

"ext-12345"

submittedAt
string<date-time>

Timestamp when the application was submitted for review. Omitted while still in progress.

Example:

"2026-01-15T09:30:00.000Z"

failureCode
enum<string>

Machine-readable failure code on rejected applications. Omitted on non-rejected applications.

Available options:
rejected_by_ops,
compliance_denied
failureMessage
string

Customer-facing failure message accompanying failureCode. Omitted on non-rejected applications.

customerId
string

Customer this onboarding application produced. Omitted while the application is still being reviewed; present after approval persists the customer row.

Pattern: ^cus_[0-9A-Za-z]{22}$
persons
object[]

People declared on the submission (beneficial owners and controlling persons), in submit order. Omitted before the application carries a submission.