Onboarding model
There are two platform models for regulated and unregulated platforms.- Regulated institutions: Use your existing compliance processes. Create individual and business customers directly via
POST /customers. The information you supply is used for beneficiary/counterparty compliance screening. - Unregulated institutions: Grid performs KYC/KYB. Generate a hosted KYC/KYB link, redirect your customer to complete verification in their locale, receive a KYC result webhook. While KYC is pending, allow customers to finish account setup but block funding and money movement.
Customer Types
The Grid API supports both individual and business customers. While the API schema itself makes most Personally Identifiable Information (PII) optional at initial creation, specific fields may become mandatory based on the currencies the customer will transact with. Your platform’s configuration (retrieved viaGET /config) includes a supportedCurrencies array. Each currency object within this array has a providerRequiredCustomerFields list. If a customer is intended to use a specific currency, any fields listed for that currency must be provided when creating or updating the customer.
The base required information for all customers is only:
- Platform customer ID (your internal identifier)
- Customer type (
INDIVIDUALorBUSINESS)
Individual customers
In some cases, only the above fields are required at customer creation. Beyond those base requirements, additional fields commonly associated with individual customers include:- Full name
- Date of birth (YYYY-MM-DD format)
- Physical address (including country, state, city, postalCode)
providerRequiredCustomerFields for each relevant currency in your platform’s configuration to determine which of these fields are strictly mandatory at creation/update time for that customer to transact in those currencies.
Business customers
Beyond the base requirements, additional fields commonly associated with business customers include:- Business information:
- Legal name (this is often required, check
providerRequiredCustomerFields) - Registration number (optional, unless specified by
providerRequiredCustomerFields) - Tax ID (optional, unless specified by
providerRequiredCustomerFields)
- Legal name (this is often required, check
- Physical address (including country, state, city, postalCode)
providerRequiredCustomerFields for each relevant currency in your platform’s configuration to determine which of these fields are strictly mandatory at creation/update time for that customer to transact in those currencies.
When creating or updating customers, the customerType field must be specified as either INDIVIDUAL or BUSINESS.
Customer Creation Process
Creating a new individual customer (regulated institutions)
To register a new customer directly, use thePOST /customers endpoint (regulated institutions):
providerRequiredCustomerFields for those currencies (found in your platform’s configuration via GET /config).
The examples below show a more comprehensive set of data. Not all fields are strictly required by the API for customer creation itself, but become necessary based on currency and provider requirements.
Example request body for an individual customer with UMA instant payments enabled (ensure all providerRequiredCustomerFields for intended currencies are included):
Typically bank account information is provided separately via internal and external account management. However, when using UMA for instant payments, since funding and withdrawals are instant, bank account information can be provided at time of customer creation.
UMA addresses follow the format
$username@domain. For your platform:- The
domainpart will be your configured UMA domain (set in platform configuration) - The
usernamepart can be chosen by you or your customers, following these rules:- Must start with a $ symbol. This is to differentiate from email addresses and clearly identify an uma address.
- The
usernameportion is limited to a-z0-9-_.+ - Addresses are case-insensitive, but by convention are written only with lowercase letters
- Like email addresses, the maximum number of characters for the
usernameportion of the address is 64 characters (including the $).
Creating a new business customer (regulated institutions)
Onboarding customers (unregulated institutions)
Unregulated institutions should initiate a hosted KYC/KYB flow. Generate a link and redirect the customer to complete verification. While KYC is pending, allow account setup but block funding and money movement.- Request a hosted KYC link for a customer using your
platformCustomerId(optionalredirectUrito return the user to your app when finished):
- Redirect the customer to
kycUrlto complete KYC/KYB in their locale. - After the user is redirected back to your app, they can continue with account setup until KYC review is complete.
- Handle the KYC status webhook. Grid notifies you when a decision is reached; update your records and unlock funding on APPROVED.
Handling KYC/KYB Webhooks
After a customer completes the KYC/KYB verification process, you’ll receive webhook notifications about their KYC status. These notifications are sent to your configured webhook endpoint.For regulated platforms, customers are created with
APPROVED KYC status by default.Content-Type: application/jsonX-Webhook-Signature: sha256=abc123...
System-generated unique identifier of the customer whose KYC status has changed.
Final KYC verification status. Webhooks are only sent for final states:
APPROVED: Customer verification completed successfullyREJECTED: Customer verification was rejectedEXPIRED: KYC verification has expired and needs renewalCANCELED: Verification process was canceledMANUALLY_APPROVED: Customer was manually approved by platformMANUALLY_REJECTED: Customer was manually rejected by platform
Intermediate states like
PENDING_REVIEW do not trigger webhook notifications. Only final resolution states will send webhook notifications.Webhook Implementation Example
Webhook Implementation Example
Customer management
Retrieving customer information
You can retrieve customer information using either the Grid-assigned customer ID or your platform’s customer ID:Data validation
The Grid API performs validation on all customer data. Common validation rules include:- All required fields must be present based on customer type
- Date of birth must be in YYYY-MM-DD format and represent a valid date
- Names must not contain special characters
- Bank account information must follow country-specific formats
- Addresses must include all required fields including country code
Bulk customer import operations
For scenarios where you need to add many customers to the system at once, the API provides a CSV file upload endpoint.CSV file upload
For large-scale customer imports, you can upload a CSV file containing customer information:- Webhook notifications (if configured)
- Status polling endpoint: