Comprendre l’API du cœur
Le cœur PI Connect permet aux canaux d’un participant d’initier et de suivre des opérations de paiement. L’application participant-api expose les services HTTP ; les traitements asynchrones sont poursuivis par le worker. Le core banking reste maître de la comptabilité.
Choisir son interface
| Interface | Destinataire | Usage |
|---|---|---|
/api/v1/{participantCode}/… | Canaux du participant | Transferts, alias, vérification, demandes de paiement et consultations |
/api/v1/{participantCode}/operations/…, /pricing-engine/… et /api/v1/ops/… | Opérateurs autorisés | Supervision, configuration et opérations de reprise |
| Routes « Callbacks PI » de la référence | Plateforme PI | Réception des messages signés sur le canal mTLS |
Routes internes /api/v1/{participantCode}/business/… | Application Business | Liaison serveur à serveur avec le cœur |
L’API Business publique est portée par une application distincte et son propre portail. Son préfixe /piz/v1 ne remplace pas celui du cœur. Les API distantes de PI-SPI et PI-RAC ne sont pas le contrat présenté ici.
Identifier le participant
participantCode est le code membre du participant configuré dans votre environnement. Il appartient au chemin de chaque opération métier. Les identifiants et les consultations doivent rester dans ce même contexte ; changer le code dans l’URL ne donne aucun droit sur un autre participant.
Lire la référence
La référence interactive provient des contrôleurs de participant-api. Elle regroupe les opérations métier, d’exploitation, les callbacks et les routes internes. Les objets libres de certaines routes sont présentés comme tels : un schéma générique ne dispense pas des contrôles métier.
Commencez par le premier appel, puis le parcours de transfert. Les parcours Postman B — Cœur complètent ces guides avec des scénarios exécutables.