Customers

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.

export API_BASE='https://platform.swipelux.com'
export SWIPELUX_API_KEY='replace-with-your-api-key'

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:

curl --request POST \
  "${API_BASE}/v3/customers" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}" \
  --header "Idempotency-Key: customer-user-123" \
  --header "Content-Type: application/json" \
  --data @- <<'JSON'
{
  "type": "individual",
  "externalId": "user_123",
  "individual": {
    "firstName": "Amina",
    "lastName": "Diallo",
    "residenceCountry": "FR"
  }
}
JSON

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:

curl --request POST \
  "${API_BASE}/v3/customers" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}" \
  --header "Idempotency-Key: customer-company-456" \
  --header "Content-Type: application/json" \
  --data @- <<'JSON'
{
  "type": "business",
  "externalId": "company_456",
  "business": {
    "legalName": "Acme Payments SAS"
  }
}
JSON

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:

curl --request POST \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/related-parties" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}" \
  --header "Idempotency-Key: related-party-director-001" \
  --header "Content-Type: application/json" \
  --data @- <<'JSON'
{
  "partyType": "person",
  "roles": ["director"],
  "title": "Chief executive officer",
  "person": {
    "firstName": "Amina",
    "lastName": "Diallo",
    "residenceCountry": "FR"
  }
}
JSON

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.

curl --request GET \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}"

Next, continue to Capabilities and tasks to discover and activate the product outcome you need.

Get started

Onboard customers

Build money flows

Launch

Individual customers

Business customers

Read readiness from capabilities

​Individual customers

​Business customers

​Add business related parties

​Read readiness from capabilities

Individual customers

Business customers

Add business related parties

Read readiness from capabilities