Clients

Créez le client avant de construire un encaissement, un paiement ou un compte bancaire émis. Les capacités, les comptes et les transferts sont liés à ce client. Utilisez externalId comme mappage stable vers l’enregistrement correspondant dans votre système.

Environment variables

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

Clients individuels

Un individu ne requiert que type. Incluez les champs de profil que vous connaissez déjà, et ajoutez-en davantage uniquement lorsque la capacité ou la tâche actuelle en a besoin. Créez le client avec POST /v3/customers :

Create individual customer

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

Stockez le data.id renvoyé en tant que CUSTOMER_ID. Consultez Onboarding individuel pour le contexte politique.

Clients professionnels

Une entreprise requiert business.legalName. Créez l’entreprise avec la même opération :

Create business customer

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

Stockez le data.id renvoyé en tant que CUSTOMER_ID. Consultez Onboarding professionnel pour le contexte politique et documentaire. Ajoutez des directeurs, des propriétaires et d’autres participants de l’entreprise lorsqu’ils sont connus ou requis. Cet exemple crée un directeur avec POST /v3/customers/{customerId}/related-parties :

Add related party

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

Stockez le data.id renvoyé en tant que RELATED_PARTY_ID. Si vous devez exporter un client, utilisez POST /v3/customers/{customerId}/export et suivez son schéma de requête. Le format json_basic_data renvoie la ressource client v3 publique actuelle sous forme de pièce jointe JSON ; chaque appel recalcule les données actuelles et exclut les documents et leurs métadonnées. Pour un format de jeton de portabilité, envoyez l’ID client du projet KYC destinataire en tant que forClientId, et non le customerId Swipelux. Utilisez le data.token renvoyé avant data.expiresAt. Réutiliser la même Idempotency-Key et le même corps rejoue ce résultat de jeton ; utilisez une nouvelle clé pour émettre un autre jeton.

Lire la disponibilité à partir des capacités

Un client n’a pas de statut de vérification ou de disponibilité dans l’API. Lisez le client avec GET /v3/customers/{customerId} pour les données de profil actuelles, puis utilisez les capacités et leurs openTaskIds pour décider de ce que le client peut faire ensuite.

Get customer

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

Trouver les clients avec des documents en attente

Pour savoir quels clients d’une page doivent encore fournir des documents obligatoires, passez include=documentRequirements à GET /v3/customers. Vous pouvez le combiner avec les résumés de capacités sous la forme include=capabilities,documentRequirements. Les clés API ont besoin de accounts:read pour l’expansion documentRequirements. Chaque résumé client inclut alors un objet documentRequirements :

Document requirement summary

{
  "documentRequirements": {
    "required": true,
    "count": 2
  }
}

count est le nombre d’exigences de documents obligatoires à l’état action_required sur des tâches qui sont aussi à l’état action_required. Il couvre toutes les portées de tâche, y compris les tâches à l’échelle du compte, et ne dépend pas de la disponibilité des capacités.
required vaut true lorsque count est supérieur à 0.
Un ensemble d’alternatives compte une seule fois, et uniquement lorsque chaque alternative exige un document.

Le résumé est prudent. Il exclut les documents facultatifs, les documents obligatoires sous condition et les alternatives qui mêlent des voies avec et sans document. Il exclut également les exigences que le client peut remplir via la vérification hébergée. Par conséquent, required: false ne prouve pas qu’aucune tâche de document ne s’applique. Utilisez-le pour prioriser les clients, puis lisez leurs tâches pour obtenir la liste de référence des éléments à collecter. Sans l’expansion, la réponse omet documentRequirements. Ensuite, continuez vers Capacités et tâches pour découvrir et activer le résultat produit dont vous avez besoin.

Commencer

Intégrer les clients

Construire les flux monétaires

Mise en production

Clients individuels

Clients professionnels

Lire la disponibilité à partir des capacités

Trouver les clients avec des documents en attente

​Clients individuels

​Clients professionnels

​Ajouter des parties liées professionnelles

​Lire la disponibilité à partir des capacités

​Trouver les clients avec des documents en attente

Clients individuels

Clients professionnels

Ajouter des parties liées professionnelles

Lire la disponibilité à partir des capacités

Trouver les clients avec des documents en attente