0808Intégration API
Ouvrir un dossier depuis votre outil.
Si vos collaborateurs saisissent un client dans votre logiciel métier puis le ressaisissent ici, la deuxième saisie finira par diverger. L’API existe pour que le dossier parte de là où le client est déjà connu.
Cette page dit à quoi ressemble une intégration et ce qu’elle demande. La référence technique complète, avec les requêtes, les réponses et le code de vérification des signatures, vit sur la page destinée aux développeurs.
01Authentification
OAuth2, portée par portée.
L’accès se fait par identifiants client OAuth2. Les jetons durent une heure : gardez-les en cache et renouvelez-les à l’expiration plutôt qu’à chaque appel.
Portées déclarées
- onboardings:read
- onboardings:write
- clients:read
- clients:write
- companies:read
- register:read
- register:write
- reports:read
- verifications:read
- verifications:write
- webhooks:manage
Demandez le jeu le plus étroit qui fasse votre travail. Les points d’entrée dossiers et registre existent aujourd’hui : reports:read et webhooks:manage sont déclarées pour des points d’entrée qui ne sont pas encore construits et n’accordent rien.
02Le parcours type
Trois appels et un dossier vivant.
L’intégration la plus courante n’essaie pas de refaire l’application. Elle crée le dossier avec ce que votre outil sait déjà, laisse la conformité se faire ici, et se tient au courant de la suite.
- GET
/api/v2/register/companies/{n}Consulter le registre
Avant d’ouvrir quoi que ce soit : identité, adresse, activités, score financier, comptes déposés et publications au Moniteur. Une entreprise que vous n’avez jamais onboardée répond aussi, parce que le registre est public.
Renvoie la fiche publique, et ce que votre organisation en sait déjà - POST
/api/v2/onboardingsCréer le dossier
Un numéro d’entreprise suffit : la fiche se pré-remplit depuis le registre officiel, donc vous n’envoyez pas des données légales que vous ne maîtrisez pas.
Renvoie l’identifiant du dossier créé - POST
/api/v2/onboardings/{id}/beneficiariesLe compléter
Ajoutez ce que votre outil détient et que le registre ne donne pas : personnes de contact, nature de la mission, pièces déjà collectées.
Renvoie le bénéficiaire ajouté au dossier - POST
/api/v2/onboardings/{id}/submitSuivre la décision
Plutôt que d’interroger l’API en boucle, laissez le webhook vous prévenir quand le dossier change d’état.
Renvoie le dossier remis à l’AMLCO, la suite arrive par webhook
03Webhooks
Signés, et à vérifier.
Chaque envoi porte une signature calculée avec votre secret partagé. Une réception non vérifiée accepterait n’importe quelle requête prétendant venir de nous, ce qui est précisément le risque que la signature existe pour écarter.
POST https://votre-app.example.com/hooks/aml
x-amlcompany-signature: v1=9f86d0818…
04Bac à sable
Essayez sans créer de vrais dossiers.
Un environnement de test permet de dérouler le parcours complet avec des données prévues pour cela, avant de brancher l’intégration sur votre organisation réelle.
Numéros d’entreprise réservés
| Numéro | Ce qui se passe |
|---|---|
| BE0999999001 | Une société complète, SANDBOX TEST SRL |
| BE0999999002 | Une société construite pour se noter en risque plus élevé |
| BE0999999404 | Toujours introuvable : le chemin qu’il ne faut jamais réessayer |
| BE0999999500 | Toujours en échec : le chemin qu’il faut réessayer |
Un bac à sable n’interroge jamais le registre officiel : vos tests dépendraient d’un tiers et de données qui bougent sous eux. Les deux derniers numéros sont l’intérêt principal, puisqu’on ne peut pas faire échouer le vrai registre à la demande.
Les identifiants du bac à sable, les numéros d’entreprise de test et les codes d’erreur reproductibles sont listés dans la référence développeur.