Skip to main content
PATCH
Update sub-client association for a customer

Authorizations

x-api-key
string
header
required

Path Parameters

customer_id
string
required

Unique identifier (ksuid) of the customer record KSUID is a 27-character globally unique ID that combines a timestamp with a random component. Used for all entity identifiers in the Dakota platform.

Required string length: 27
Pattern: ^[0-9A-Za-z]{27}$
Example:

"1NFHrqBHb3cTfLVkFSGmHZqdDPi"

Body

application/json

Request to update the sub-client association for a customer. Set sub_client_id to associate with a sub-client, or null to disassociate.

sub_client_id
string | null

ID of the sub-client to associate with, or null to disassociate.

Required string length: 27
Pattern: ^[0-9A-Za-z]{27}$
Example:

"1NFHrqBHb3cTfLVkFSGmHZqdDPi"

Response

Sub-client association updated successfully

Response containing the current status of a KYB verification process including provider-specific statuses.

id
string
required

KSUID is a 27-character globally unique ID that combines a timestamp with a random component. Used for all entity identifiers in the Dakota platform.

Required string length: 27
Pattern: ^[0-9A-Za-z]{27}$
Example:

"1NFHrqBHb3cTfLVkFSGmHZqdDPi"

name
string
required

Name of the customer

Example:

"Acme Corp"

customer_type
enum<string>
required

Type of entity - either an individual person or a company/organization

Available options:
individual,
business
Example:

"business"

kyb_status
enum<string>
required

Overall status of the KYB verification process (e.g., pending, active, restricted).

Available options:
active,
pending,
partner_review,
rejected,
frozen,
auto_declined
Example:

"pending"

kyc_status
enum<string>
required

Provider-agnostic effective KYC/B status for this customer, derived server-side for display convenience. Returns the same answer for both Sumsub-verified and Persona-verified customers without the client having to know which provider did the work.

Derivation order (most authoritative first):

  1. The customer's onboarding application decision, if set (approvedapproved; declined/auto_declinedrejected; withdrawnexpired).
  2. The most-recently-updated non-deleted persona kyb_link's status (legacy customers from before the orchestration layer — Persona's created maps to not_started, completed to approved, needs_review to in_review).
  3. pending if the customer has an open onboarding application but no decision yet (Sumsub in-flight).
  4. not_started otherwise.

Advisory, not authoritative. This field is provided for badge rendering and operator UIs. The derivation rules may evolve as new verification providers are added. For compliance-critical decisions, consult decision, kyb_links, and provider_statuses directly.

Available options:
not_started,
pending,
expired,
approved,
rejected,
in_review
Example:

"pending"

created_at
integer
required

Timestamp of when the link was created

Example:

1234567890

updated_at
integer
required

Timestamp of when the link was last updated.

Example:

1234567890

email
string

Email address of the customer

Example:

"contact@acmecorp.com"

external_id
string

Unique identifier for the customer in the client's system, as supplied when the customer was created. Omitted when no external ID was set.

Example:

"external_customer_123"

KYB Links for different providers used in the KYB process.

provider_statuses
object[]

Detailed status information from different verification providers used in the KYB process.

rd_allowed
boolean

Whether this customer is currently permitted to hold RD, derived server-side from the same US-state geofence that guards RD account creation. true when RD is allowed; false only when one of the customer's governing US states is on the restricted list while the geofence is active. Customers with no resolvable US governing state — non-US customers, or those whose jurisdiction is unconfirmed — are allowed. When the geofence is disabled (empty blocklist) this is true for everyone.

This is the canonical read path for the RD-eligibility verdict: consumers read a boolean and never see or copy the underlying blocklist.

Example:

true

application_id
string

ID of the KYB application associated with this customer

Required string length: 27
Pattern: ^[0-9A-Za-z]{27}$
Example:

"1NFHrqBHb3cTfLVkFSGmHZqdDPi"

application_status
enum<string>

Current lifecycle state of the customer's onboarding application (e.g. pending, submitted, under_review, approved, declined). Omitted when the customer has no application.

Use this field to drive workflow UI — it tracks where the customer is in the onboarding flow. For the orthogonal questions "is this customer cleared to transact?" and "what's the provider-agnostic KYC verdict?", see kyb_status and kyc_status respectively.

Available options:
pending,
submitted,
under_review,
request_for_information,
admin_revision,
approved,
declined,
completed,
compliance_review
Example:

"submitted"

decision
enum<string>

Application decision status

Available options:
approved,
declined,
auto_declined,
withdrawn
Example:

"approved"

decision_reason
string

Why the application was decided. Populated for withdrawn/declined applications — for example, the fixed reason recorded when an applicant withdraws from an RFI resubmission email. Omitted when there is no decision or no reason was recorded.

Example:

"User withdrew the application from the request-for-information (RFI) email"

status
enum<string>

The single client-facing status for this customer, derived server-side. It collapses three signals into one badge so a client never has to reconcile kyb_status, kyc_status, and application_status by hand.

Precedence (first match wins):

  1. frozen — the customer has an open freeze; surfaced over a stale approval so an actionable freeze is never masked.
  2. the most-recent application's decision — approved, declined (declined or auto_declined), or withdrawn.
  3. the most-recent application's lifecycle — info_requested when a request for information is open (the customer owes a response); the internal in-review states collapse to submitted; pending otherwise.
  4. pending when the customer has no application yet.

Once a customer is approved / declined / withdrawn, that is the final answer and kyb_status / kyc_status do not change it. Use those fields only for the underlying breakdown.

Available options:
frozen,
declined,
withdrawn,
approved,
info_requested,
submitted,
pending
Example:

"info_requested"

application_url
string

URL for accessing the onboarding application. Always present when the customer has an onboarding application, including during an open RFI loop. In an RFI loop the additive resubmit_url is returned as well, and the dashboard links to that resubmission page rather than this plain application view.

Example:

"https://onboarding.example.com/applications/abc123?token=xyz789"

resubmit_url
string

The resubmission link for a customer in an open RFI loop — the exact /applications/{id}/resubmit?token=… URL the applicant receives in the RFI email, built from the customer's existing onboarding token (no new token is minted on read). Present only when status is info_requested, and returned alongside application_url rather than in place of it.

Example:

"https://onboarding.example.com/applications/abc123/resubmit?token=xyz789"

deleted_at
integer

Timestamp of when the link was deleted

Example:

1234567890

sub_client_id
string

ID of the sub-client this customer is associated with, if any.

Required string length: 27
Pattern: ^[0-9A-Za-z]{27}$
Example:

"1NFHrqBHb3cTfLVkFSGmHZqdDPi"

sub_client_name
string

Name of the sub-client this customer is associated with, if any.

Example:

"Partner Corp"

is_sub_client
boolean
default:false

Whether this customer is a sub-client. This is set when the customer is created and cannot be changed afterwards.