Skip to main content
Customers are the foundation of the Infinite platform. They represent individuals or businesses that will be onboarded for verification and payment processing.

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)
Additional Restricted Countries:
  • Ukraine (UA)
Attempting to create or update a customer with a country code from a restricted country will result in a 400 Bad Request error. The country selection will be automatically filtered in the verification UI.

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?

  1. Progressive data collection: Build up customer data over multiple API calls without triggering validation until you’re ready
  2. Flexible workflows: Collect information in any order, from any source
  3. Clear submission point: Explicitly control when verification begins
  4. 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

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

Business customers use 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 to NEED_ACTIONS and the response includes missingFields and/or missingDocuments.
To resolve:
  1. Add the missing data via PATCH /customers/:id
  2. Upload any missing documents via POST /documents
  3. Re-submit via POST /customers/:id/submit

Customer Data

Required Fields

  • customerName - Full name (individual) or company name (business)
Customer type is chosen by the endpoint: POST /customers/individuals or POST /customers/businesses. Do not send type on those requests.
  • email - Primary contact email address
  • countryCode - 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, middleName
  • dateOfBirth (YYYY-MM-DD format)
  • phone with country code
  • occupation, 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, tradeName
  • businessType (LLC, Corp, etc.)
  • taxId
  • yearEstablished
  • website, industry

Working with Customers

Retrieving Customers

Get All Customers

Get Specific Customer

Filter by Status

Updating Customers

Update customer data at any time while in DRAFT or NEED_ACTIONS status: For individual customer profile updates, send occupation as an occupation code and sourceOfIncome as an enum value.

Best Practices

Always include an Idempotency-Key header when creating customers to prevent duplicate records from retries.
Use the intent pattern to collect data across multiple sessions or sources without worrying about validation until submission.
Check missingFields and missingDocuments on customer responses to understand what’s needed before submission.
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