Get customer requirements
Preview the requirements a hypothetical customer of the given
customerType and jurisdiction would need to satisfy to enable the
requested capabilities, without creating a customer record.
Partner onboarding UIs can use this to render the collection flow
before any customer state exists.
Today this endpoint only previews the Terms of Service requirement:
the response’s RequirementsMap will only ever contain a tos key.
Other requirement families (PII / CDD inputs) are not yet available
through this endpoint; use POST /v2/customers or
PUT /v2/customers/{customerId} to discover those via
Customer.requirements.
Only customerType: individual customers resident in or citizens
of the US are currently supported; every other combination returns
400 invalid_request.
Authorizations
A JWT signed using your CDP API Key Secret, encoded in base64. Refer to the Generate Bearer Token section of our Authentication docs for information on how to generate your Bearer Token.
Query Parameters
The type of the hypothetical customer. The type of the customer. Required on create; accepted but ignored on update.
individual "individual"
The capabilities the hypothetical customer would request.
Repeat the parameter to specify multiple capabilities, for
example capabilities=custodyCrypto&capabilities=transferCrypto.
1The name of a capability. Capabilities represent granular functional permissions that determine what actions a customer can perform. Each capability must be explicitly requested before use.
custodyCrypto, custodyFiat, custodyStablecoin, tradeCrypto, tradeStablecoin, transferCrypto, transferFiat, transferStablecoin The hypothetical customer's country of residence. At least one
of countryCode or citizenship is required. When both are
present, countryCode takes precedence.
An ISO 3166-1 alpha-2 country code.
2^[A-Z]{2}$"US"
The hypothetical customer's citizenship. At least one of
countryCode or citizenship is required.
An ISO 3166-1 alpha-2 country code.
2^[A-Z]{2}$"US"
Response
Successfully previewed requirements.
Map of requirements to be submitted. Each key is the field name (e.g., "ssnLast4"), with values to describe its state. Requirements are only shown for requested capabilities. When a requirement is verified, it disappears from this map.
For the tos key, each entry in tosVersions[] has its own optional
deadline. The requirement-level deadline is an aggregate of those rows:
the earliest set deadline among unaccepted versions, not a separate clock.
A version with no deadline requires immediate acceptance but keeps the
aggregate status due. A future deadline is also due and represents
non-blocking grace. The aggregate status is past_due only when at least
one unaccepted version has a deadline set in the past. Do not infer status
or blocking behavior from omission of the aggregate deadline.
A single requirement that a customer must submit to enable capabilities. Requirements are only shown for requested capabilities.