Intégration internal-api
L’internal-api est le back-office Symfony / Doctrine d’erevo (API Platform), consommé par le monorepo via des clients tRPC. La facturation s’y appuie pour lire l’état réel des sessions et des étudiants, et pour persister les dossiers de facturation.
Authentification
Section intitulée « Authentification »Le client (librairies/trpc/src/context/internal-api-client) est une instance Axios pointant sur
{internalApiUrl}{internalApiSuffix} (p. ex. https://api.example.com/api/v1), avec l’en-tête
X-AUTH-TOKEN. Côté billing, l’URL et la clé proviennent de REACT_APP_INTERNAL_API_URL /
REACT_APP_INTERNAL_API_KEY.
Entités lues / écrites par la facturation
Section intitulée « Entités lues / écrites par la facturation »| Endpoint | Méthode | Usage |
|---|---|---|
/sessions/list | POST | Récupérer les sessions par identifiants de transaction HubSpot |
/sessions/{id}/dispatch | GET | Récupérer une session complète |
/sessions?student.user.id=… | GET | Sessions d’un utilisateur (self-funded) |
/sessions?crmID[]=… | GET | Récupération par lot par id de deal (confirmation webhook FIFPL) |
/session_documents?session.id[]=…&documentSlug=signature | GET | Documents de signature |
/consent_approbations?… | GET | Consentements e-signature (statut, clé S3, journaux de signature) |
/training_leafs?version.reference=… | GET | Feuilles de formation (génération des relevés d’activité) |
/virtual_classes?sessionDate.id=… | GET | Données de classe virtuelle (traitement des journaux) |
/billing_files/{id} | PATCH | Mettre à jour le dossier de facturation (numéro de facture, avoir…) |
Les structures principales : SessionAPIFull (étudiant avec crmId, noms DPC/FIFPL, date et nom
de naissance ; produit ; dates ; activités), FundingAPIFull (configuration financeur),
ConsentApprobationAPI (consentement signé, clé S3, PDF, journaux), VirtualClassAPI
(formateurs, modules, dates de session associées).
Le webhook HubSpot → internal-api
Section intitulée « Le webhook HubSpot → internal-api »Point clé de l’automatisation FIFPL : la facturation écrit dans HubSpot, mais les noms FIFPL ne deviennent corrects côté session qu’après la descente HubSpot → internal-api, opérée par un webhook asynchrone.
C’est pourquoi, après la synchro, l’app interroge l’internal-api en boucle (/sessions?crmID[]=…)
jusqu’à voir les noms attendus sur la session (nameFieldsMatch). Sans cette confirmation, relancer
la mutation serait un no-op et la suite du parcours resterait bloquée.
Sous le capot
Section intitulée « Sous le capot »- Client de contexte :
librairies/trpc/src/context/internal-api-client/index.ts(base URL +X-AUTH-TOKEN). - Contrôleurs tRPC consommateurs :
librairies/trpc/src/controller/billing/index.ts(getSessionsByCRMIds,getSingleSession,getSessionsDocuments,getSessionsByCrmIdFilter,getConsentApprobations,updateBillingFileBillNumber,generateDocumentProps). - Persistance du dossier : le
billing_fileest sauvegardé avec ses médias (IRIs des PDF uploadés) — voir Documents & signatures.