This guide provides comprehensive information about customer configuration in the Grid API, including customer types, registration processes, management, and bank account information.Documentation Index
Fetch the complete documentation index at: https://ramps-docs-sync-onboarding-examples.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
Customer Types
The Grid API supports both individual and business customers. While the API schema itself makes most Personally Identifiable Information (PII) optional at the initial customer 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. 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.
Customer Registration Process
Creating a New Customer
When creating or updating customers, thecustomerType field must be specified as either INDIVIDUAL or BUSINESS. Depending if you are a regulated or unregulated platform your KYC/KYB requirements will vary.
Regulated Platforms
Regulated Platforms
Regulated platforms have lighter KYC requirements since they handle compliance verification internally.
- Direct API Onboarding: Create customers directly via API calls with minimal verification
- Internal KYC/KYB: Handle identity verification through your own compliance systems
- Reduced Documentation: Only provide essential customer information required by your payment counterparty or service provider.
- Faster Onboarding: Streamlined process for known, verified customers
Creating Customers via Direct API
For regulated platforms, you can create customers directly through the API without requiring external KYC verification:To register a new customer in the system, use thePOST /customers endpoint:- Individual customer
- Business Customer
Unregulated Platforms
Unregulated Platforms
Unregulated platforms rely on Grid to run KYC for individuals and KYB for businesses. You can onboard customers either through the hosted KYC/KYB link flow below, or by submitting customer data directly through the API. Both paths produce the same
kycStatus transitions and emit the same CUSTOMER.KYC_APPROVED / CUSTOMER.KYC_REJECTED / CUSTOMER.KYC_PENDING (and CUSTOMER.KYB_* equivalents) webhooks.- Hosted flow: Redirect customers to a Grid-hosted link (or embed the provider SDK) for identity verification. Best when you want Grid to handle the entire collection UX.
- Direct API onboarding: Collect customer information in your own UI and submit it via the API. For
INDIVIDUALcustomers (KYC), personal information goes throughPOST /customers. ForBUSINESScustomers (KYB), you also register beneficial owners viaPOST /beneficial-owners. Submit for review withPOST /verifications.
Hosted KYC Link Flow
The hosted KYC flow provides a secure, hosted interface where customers can complete their identity verification and onboarding process.The flow is two steps: create the customer with the information you have, then generate a hosted KYC link for that customer. The customer’skycStatus stays PENDING until they complete the hosted flow.1. Create the customer
Create the customer withPOST /customers, supplying at least customerType and any fields you already have. See Configuring Customers for the full list of optional pre-fill fields.id (the Grid customer ID) — you’ll need it for the next step.2. Generate a KYC link
Complete KYC Process
Create the customer
Call
POST /customers with customerType and any pre-fill fields you have. The returned id is the customer’s Grid ID; their kycStatus is PENDING until verification completes.Generate the KYC link
Call
POST /customers/{customerId}/kyc-link. Each call returns a fresh single-use kycUrl and expiresAt; previously-issued links remain single-use but aren’t invalidated.The
redirectUri you pass is embedded in the generated kycUrl and is used to automatically return the customer to your application after they complete verification.Send the customer through verification
Redirect the customer to
kycUrl, or — if you want to embed the flow directly — initialize the provider’s SDK with the returned token.Track the decision
Reaching your
redirectUri only means the customer finished the hosted flow — not that they were approved. Wait for the final decision in one of two ways:- Webhook (recommended): Subscribe to
CUSTOMER.KYC_APPROVED/CUSTOMER.KYC_REJECTED(andCUSTOMER.KYB_APPROVED/CUSTOMER.KYB_REJECTEDfor business customers) to be notified when the customer reaches a terminal status.CUSTOMER.KYC_PENDING(and theKYB_PENDINGsibling) also fires when the customer is submitted for review — subscribe to it as well if you want to surface an “under review” state to the customer. - Polling: Call
GET /customers/{customerId}and inspectkycStatus.
Direct API Onboarding
Prefer to collect identity information in your own UI and submit it to Grid yourself? Use the API directly instead of redirecting to a hosted link. The customer’skycStatus transitions the same way and you receive the same CUSTOMER.KYC_APPROVED / CUSTOMER.KYC_REJECTED / CUSTOMER.KYC_PENDING (and CUSTOMER.KYB_* equivalents) webhooks.The shape of the flow depends on the customer type:- KYC (
INDIVIDUALcustomers) — supply the customer’s personal information through the customer endpoint. No beneficial owners are involved. - KYB (
BUSINESScustomers) — create the business customer, then register its beneficial owners, directors, and officers individually.
- KYC (individual)
- KYB (business)
Create the customer with personal information
Call
POST /customers with customerType: INDIVIDUAL and the personal information collected from the customer (legal name, date of birth, address, nationality, etc.). The returned id is the customer’s Grid ID; kycStatus starts at PENDING.Upload supporting documents (if requested)
Some jurisdictions or currencies require an ID document or proof of address. Upload them with
POST /documents using multipart/form-data, referencing the customer by customerId.Submit for verification
Call Submitted successfully:Blocked by missing data:
POST /verifications to submit the customer for review. The response includes a verificationStatus. If anything is missing, verificationStatus is RESOLVE_ERRORS and the errors array describes exactly what to collect before retrying.Track the decision
Track terminal
kycStatus transitions via the CUSTOMER.KYC_APPROVED / CUSTOMER.KYC_REJECTED webhook (recommended) or by polling GET /customers/{customerId}. CUSTOMER.KYC_PENDING also fires when the customer is submitted for review — subscribe to it if you want to surface an “under review” state. On APPROVED, unlock funding and money movement.Customer Management
Retrieving Customer Information
You can retrieve customer information using either the Grid-assigned customer ID or your platform’s customer ID:Updating Customer Information
To update customer information:customerType discriminator is required on PATCH so the API knows which set of optional fields to validate. To update bank-account details, use the /customers/external-accounts endpoints — bank accounts are no longer managed inline on the customer resource.
Bank Account Information
The API supports various bank account formats based on country and funding type. There are two types of funding mechanisms supported by Grid: an omnibus FBO (for benefit of) account owned by the platform, or direct customer-owned accounts. You must provide the correct format based on the customer’s region and bank account type.Optional Platform Account ID
All bank account types support an optionalplatformAccountId field that allows you to link bank accounts to your internal systems. This field can be any string that helps identify the account in your platform (e.g., database IDs, custom references, etc.).
Example with platform account ID:
platformAccountId:
- Tracking multiple bank accounts and uma addresses for the same customer
- Linking accounts to internal accounting systems
- Maintaining consistency between the Grid API and your platform’s account records
- Facilitating account reconciliation and reporting
FBO Accounts
FBO Accounts
FBO accounts are used when the platform has a single omnibus account that is used to fund all customers. Account details
must be provided manually at the platform level. For each customer, during you should simply provide:
Mexico: CLABE
Mexico: CLABE
United States: ACH (Account and Routing Number)
United States: ACH (Account and Routing Number)
Brazil PIX
Brazil PIX
CPF, CNPJ, PHONE, EMAIL, or RANDOM.India: UPI (Unified Payments Interface)
India: UPI (Unified Payments Interface)
International: IBAN
International: IBAN
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 or excessive spaces
- Bank account information must follow country-specific formats
- Addresses must include all required fields including country code
Best Practices
- Identity Verification: Choose a proper KYC/KYB identity verification flow as detailed in the Quickstart Guide
- Data Security: Store and transmit customer data securely, following data protection regulations
- Regular Updates: Keep customer information up to date, especially banking details
- Error Handling: Implement proper error handling to manage validation failures gracefully
- Idempotent Operations: Use your platformCustomerId consistently to avoid duplicate customer creation
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 endpoint:
CSV Format
The CSV file should have the following columns: Required columns for all customers:- umaAddress: The customer’s UMA address (e.g.,
$john.doe@uma.domain.com) - platformCustomerId: Your platform’s unique identifier for the customer
- customerType: Either “INDIVIDUAL” or “BUSINESS”
- fullName: Individual’s full name
- birthDate: Date of birth in YYYY-MM-DD format
- addressLine1: Street address line 1
- city: City
- state: State/Province/Region
- postalCode: Postal/ZIP code
- country: Country code (ISO 3166-1 alpha-2)
- businessLegalName: Legal name of the business
- addressLine1: Street address line 1
- city: City
- state: State/Province/Region
- postalCode: Postal/ZIP code
- country: Country code (ISO 3166-1 alpha-2)
- addressLine2: Street address line 2
- platformAccountId: Your platform’s identifier for the bank account
- description: Optional description for the customer
- email: Customer’s email address
- businessRegistrationNumber: Business registration number
- businessTaxId: Tax identification number
/customers/external-accounts endpoints.