Skip to main content
GET
Get customer requirements

Authorizations

Authorization
string
header
required

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

customerType
enum<string>
required

The type of the hypothetical customer. The type of the customer. Required on create; accepted but ignored on update.

Available options:
individual
Example:

"individual"

capabilities
enum<string>[]
required

The capabilities the hypothetical customer would request. Repeat the parameter to specify multiple capabilities, for example capabilities=custodyCrypto&capabilities=transferCrypto.

Minimum array length: 1

The 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.

Available options:
custodyCrypto,
custodyFiat,
custodyStablecoin,
tradeCrypto,
tradeStablecoin,
transferCrypto,
transferFiat,
transferStablecoin
countryCode
string

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.

Required string length: 2
Pattern: ^[A-Z]{2}$
Example:

"US"

citizenship
string

The hypothetical customer's citizenship. At least one of countryCode or citizenship is required.

An ISO 3166-1 alpha-2 country code.

Required string length: 2
Pattern: ^[A-Z]{2}$
Example:

"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.

{key}
object

A single requirement that a customer must submit to enable capabilities. Requirements are only shown for requested capabilities.

Example: