Naar hoofdinhoud gaan
Maak de klant aan voordat je een pay-in, uitbetaling of uitgegeven bankrekening bouwt. Capabilities, accounts en transfers zijn scoped aan die klant. Gebruik externalId als de stabiele mapping naar het bijbehorende record in jouw systeem.
Environment variables

Individuele klanten

Een individu vereist alleen type. Voeg profielvelden toe die je al kent en voeg er alleen meer toe wanneer de huidige capability of taak ze nodig heeft. Maak de klant aan met POST /v3/customers:
Create individual customer
Bewaar de geretourneerde data.id als CUSTOMER_ID. Zie Individuele onboarding voor beleidscontext.

Zakelijke klanten

Een bedrijf vereist business.legalName. Maak het bedrijf aan met dezelfde operation:
Create business customer
Bewaar de geretourneerde data.id als CUSTOMER_ID. Zie Zakelijke onboarding voor beleids- en documentcontext. Voeg bestuurders, eigenaren en andere zakelijke deelnemers toe wanneer ze bekend of gevraagd zijn. Dit voorbeeld maakt een bestuurder aan met POST /v3/customers/{customerId}/related-parties:
Add related party
Bewaar de geretourneerde data.id als RELATED_PARTY_ID. Als je een klant moet exporteren, gebruik je POST /v3/customers/{customerId}/export en volg je het requestschema. Het json_basic_data-formaat retourneert de huidige publieke v3-klantresource als JSON-bijlage; elke aanroep berekent de huidige data opnieuw en sluit documenten en documentmetadata uit. Stuur voor een portability-token-formaat de client-ID van het ontvangende KYC-project als forClientId, niet de Swipelux customerId. Gebruik het geretourneerde data.token vóór data.expiresAt. Hergebruik van dezelfde Idempotency-Key en body replayt dat tokenresultaat; gebruik een nieuwe key om een ander token uit te geven.

Lees readiness uit capabilities

Een klant heeft geen verificatie- of readiness-status in de API. Lees de klant met GET /v3/customers/{customerId} voor huidige profieldata en gebruik vervolgens capabilities en hun openTaskIds om te bepalen wat de klant vervolgens kan doen.
Get customer

Klanten met openstaande documenten vinden

Om te zien welke klanten op een pagina nog verplichte documenten moeten aanleveren, geef je include=documentRequirements mee aan GET /v3/customers. Je kunt dit combineren met capability-samenvattingen als include=capabilities,documentRequirements. API-sleutels hebben accounts:read nodig voor de documentRequirements-expansie. Elke klantsamenvatting bevat dan een documentRequirements-object:
Document requirement summary
  • count is het aantal verplichte documentvereisten in action_required op taken die ook in action_required staan. Het omvat elke taakscope, inclusief accountbrede taken, en is niet afhankelijk van capability-readiness.
  • required is true wanneer count groter is dan 0.
  • Een set alternatieven telt één keer, en alleen wanneer elk alternatief een document vereist.
De samenvatting is conservatief. Ze sluit optionele documenten, voorwaardelijk verplichte documenten en alternatieven die document- en niet-documentroutes combineren uit. Ze sluit ook vereisten uit die de klant via hosted verificatie kan voltooien. Daardoor bewijst required: false niet dat er geen documenttaak van toepassing is. Gebruik de samenvatting om klanten te prioriteren en lees daarna hun taken voor de gezaghebbende lijst van wat je moet verzamelen. Zonder de expansie laat de response documentRequirements weg. Ga vervolgens naar Capabilities en tasks om de gewenste productuitkomst te ontdekken en te activeren.