Skip to main content
GET
Discover feature requirements for a customer

Authorizations

x-api-key
string
header
required

Path Parameters

customerId
string
required
Example:

"cus_1A2b3C4d5E6f7G8h9I0jKl"

Query Parameters

type
enum<string>
required

Feature whose requirements you want to discover.

Available options:
virtual_account,
crypto_wallet
asset
enum<string>

Target currency for the feature. Narrows the requirements to the providers that can hold it. Ignored by feature types that take no asset. Omit it to resolve over every eligible provider.

Available options:
AED,
ARS,
AUD,
BRL,
CAD,
CHF,
CLP,
CNY,
COP,
CZK,
DKK,
EGP,
EUR,
GBP,
GHS,
HKD,
HUF,
IDR,
ILS,
INR,
JPY,
KES,
KRW,
MXN,
MYR,
NGN,
NOK,
NZD,
PEN,
PHP,
PLN,
SAR,
SEK,
SGD,
THB,
TRY,
TWD,
USD,
VND,
ZAR

Response

schemaVersion
enum<string>
required

Discovery response schema version. Bumps on any breaking discovery-response change (field renamed, removed, type changed, conditional semantics changed). Distinct from the webhook envelope's apiVersion which tracks the API major. Clients pin the literal and fail loudly on mismatch; servers do not negotiate.

Available options:
3
context
enum<string>
required

The discovery context that produced this requirements set.

Available options:
onboarding,
feature,
order
Example:

"onboarding"

country
string
required

ISO 3166-1 alpha-3 country code the requirements were resolved for. Always three uppercase letters.

Pattern: ^[A-Z]{3}$
Example:

"USA"

fields
object[]
required

Scalar fields the integrator must collect, with format hints and allowedValues for enum fields.

documents
object[]
required

Customer-level documents to collect. Rows are usually keyed by canonicalType — EXCEPT address-targeted proof-of-address, which can appear as two rows sharing canonicalType PROOF_OF_ADDRESS disambiguated by addressTarget (registered / operating); collect both, and key those rows on addressTarget, not canonicalType alone. Upload every requiredArtifacts[] entry and any one alternatives[] entry when present, otherwise upload the row itself via POST /v2/documents.

minDocuments
integer
required

Document floor: the minimum number of customer-level documents POST /v2/onboarding accepts — currently 0 or 1. 1 means at least one customer-level document must be uploaded before submit (submitting documentIds: [] is rejected with 422 ONBOARDING_NOT_READY); 0 means documents are optional at submit. This is the authoritative floor — individual documents[] rows are a checklist of acceptable types and do not each carry a required flag; per-document completeness is assessed after submission.

Required range: 0 <= x <= 9007199254740991
Example:

1

individualRequirements
object[]
required

Per-role count and person-level field + document requirements for ownership.persons[].