Skip to main content
Create the customer before you build a pay-in, payout, or issued bank account. Capabilities, accounts, and transfers are scoped to that customer. Use externalId as the stable mapping to the corresponding record in your system.
Environment variables

​
Individual customers

An individual requires only type. Include profile fields you already know, and add more only when the current capability or task needs them. Create the customer with POST /v3/customers:
Create individual customer
Store the returned data.id as CUSTOMER_ID. See Individual onboarding for policy context.

​
Business customers

A business requires business.legalName. Create the business with the same operation:
Create business customer
Store the returned data.id as CUSTOMER_ID. See Business onboarding for policy and document context. Add directors, owners, and other business participants when they are known or requested. This example creates a director with POST /v3/customers/{customerId}/related-parties:
Add related party
Store the returned data.id as RELATED_PARTY_ID. If you need to export a customer, use POST /v3/customers/{customerId}/export and follow its request schema. The json_basic_data format returns the current public v3 customer resource as a JSON attachment; each call recomputes current data and excludes documents and document metadata. For a portability-token format, send the receiving KYC project’s client ID as forClientId, not the Swipelux customerId. Use the returned data.token before data.expiresAt. Reusing the same Idempotency-Key and body replays that token result; use a new key to issue another token.

​
Read readiness from capabilities

A customer does not have a verification or readiness status in the API. Read the customer with GET /v3/customers/{customerId} for current profile data, then use capabilities and their openTaskIds to decide what the customer can do next.
Get customer

​
Find customers with outstanding documents

To find which customers on a page still owe mandatory documents, pass include=documentRequirements to GET /v3/customers. You can combine it with capability summaries as include=capabilities,documentRequirements. API keys need accounts:read for the documentRequirements expansion. Each customer summary then includes a documentRequirements object:
Document requirement summary
  • count is the number of mandatory document requirements in action_required on tasks that are also in action_required. It covers every task scope, including account-wide tasks, and does not depend on capability readiness.
  • required is true when count is greater than 0.
  • A set of alternatives counts once, and only when every alternative requires a document.
The summary is conservative. It excludes optional documents, conditionally required documents, and alternatives that mix document and non-document routes. It also excludes requirements the customer can complete through hosted verification. As a result, required: false does not prove that no document task applies. Use it to prioritize customers, then read their tasks for the authoritative list of what to collect. Without the expansion, the response omits documentRequirements.

​
Read customer transfer volume

To show how much money a customer has moved, call GET /v3/customers/{customerId}/transfer-totals. API keys need customers:read. An unknown customer returns 404 customer_not_found.
Transfer totals
  • Only completed transfers count. Pending and failed transfers are excluded.
  • received sums pay-ins and inbound wallet transfers from other customers. sent sums payouts and outbound wallet transfers.
  • USD, USDC, and USDT count 1:1 as USD. Amounts in other currencies are excluded.
  • Transfers between the customer’s own wallets are excluded.
  • Each amount is a decimal string with two places, and "0.00" when no transfers qualify.
The totals are movement volume, not a current balance. Next, continue to Capabilities and tasks to discover and activate the product outcome you need.