Restricted Countries
Infinite cannot onboard customers from certain countries due to regulatory restrictions. These include OFAC-sanctioned countries and other jurisdictions with compliance limitations. OFAC Sanctioned Countries:- Cuba (CU)
- Iran (IR)
- North Korea (KP)
- Russia (RU)
- Syria (SY)
- Ukraine (UA)
Customer Types
Infinite supports two primary customer types:Individual Customers
Individual customers represent natural persons who need to complete personal KYC verification.Business Customers
Business customers represent companies or organizations that require business verification and beneficial ownership disclosure.Intent-Based State Machine
Customer creation follows an intent-based state machine pattern. This means you create a customer as an “intent” in DRAFT status, progressively add data, and explicitly submit when ready for verification.Compliance can also move a customer to
INACTIVE or SUSPENDED from any non-terminal status, and reopen a REJECTED or INACTIVE customer for re-review.Why Intent-Based?
- Progressive data collection: Build up customer data over multiple API calls without triggering validation until you’re ready
- Flexible workflows: Collect information in any order, from any source
- Clear submission point: Explicitly control when verification begins
- RFI handling: Easy loop for handling requests for additional information
Customer Status
ACTIVE means the customer passed Infinite’s compliance review — it is a prerequisite for transacting, not a guarantee that every capability is ready. Individual capabilities (e.g. balance accounts, specific payment rails) become READY as their underlying onboarding completes. Check the customer capabilities endpoint or subscribe to customer.capability.updated webhooks.Customer Creation Patterns
Pattern 1: Intent-First (Recommended)
Create customer in DRAFT status, add data progressively, then submit.1
Create Intent
Create customer with basic info. Customer starts in
DRAFT status.2
Add Data
Use
PATCH /customers/:id to add verification data, documents, addresses as you collect them.3
Submit
Call
POST /customers/:id/submit when ready. Customer transitions to IN_REVIEW.4
Handle RFI (if needed)
If status becomes
NEED_ACTIONS, add missing data via PATCH and re-submit.Step 1: Create Intent
Step 2: Add Data
Step 3: Submit
Pattern 2: Immediate Submission
If you have all data upfront, create the customer first, then save verification and request review in the same call using?submit=true.
Step 1: Create Customer
Step 2: Save and Submit
POST /customers/businesses then
POST /customers/:id/verification/business.
?submit=true does not fail when data is incomplete. The payload is saved and
the customer stays in DRAFT with missingRequirements. Status becomes
IN_REVIEW only after every required field and document is present. Check
customer compliance requirements
or the individual verification
payload for the full set.Handling Request for Information (RFI)
When verification requires additional data, the customer status changes toNEED_ACTIONS and the response includes missingFields and/or missingDocuments.
- Add the missing data via
PATCH /customers/:id - Upload any missing documents via
POST /documents - Re-submit via
POST /customers/:id/submit
Customer Data
Required Fields
customerName- Full name (individual) or company name (business)
POST /customers/individuals or
POST /customers/businesses. Do not send type on those requests.
Recommended Fields
email- Primary contact email addresscountryCode- ISO 3166-1 alpha-2 country code
Core Profile Fields
Send profile fields at the top level of the create request —POST /customers/individuals for individuals and POST /customers/businesses for businesses.
Use customerDetails on PATCH /customers/:id when updating the saved customer profile.
Use POST /customers/:id/verification/individual or POST /customers/:id/verification/business for full verification payloads.
For Individual customers:
firstName,lastName,middleNamedateOfBirth(YYYY-MM-DD format)phonewith country codeoccupation,sourceOfIncome- Transliteration fields when names contain non-Latin characters
occupation should be provided as an occupation code, for example 151252.
sourceOfIncome is an enum field and should use values like SALARY, COMPANY_FUNDS, INVESTMENTS_LOANS, INHERITANCE, SAVINGS, or PENSION_RETIREMENT.
For Business customers:
businessName,tradeNamebusinessType(LLC, Corp, etc.)taxIdyearEstablishedwebsite,industry
Working with Customers
Retrieving Customers
Get All Customers
Get Specific Customer
Filter by Status
Updating Customers
Update customer data at any time while inDRAFT or NEED_ACTIONS status:
For individual customer profile updates, send occupation as an occupation code and sourceOfIncome as an enum value.
Best Practices
Use idempotency keys
Use idempotency keys
Always include an
Idempotency-Key header when creating customers to prevent duplicate records from retries.Collect data progressively
Collect data progressively
Use the intent pattern to collect data across multiple sessions or sources without worrying about validation until submission.
Handle RFI proactively
Handle RFI proactively
Check
missingFields and missingDocuments on customer responses to understand what’s needed before submission.Monitor status via webhooks
Monitor status via webhooks
Subscribe to
customer.status_changed webhooks to react to status changes, and customer.capability.updated to know when a capability becomes ready.Next Steps
Once you’ve created a customer, the next step is typically to initiate verification to comply with KYC/AML requirements.Verification
Learn how to verify customer identities for compliance
Create Customer API
Full API reference for customer creation