Configurer les capabilities SMP, la Peppol Directory et la businessCard via l'API PSB.
La PSB est un Peppol Access Point certifié et un SMP (Service Metadata Publisher). Via l'API, vous configurez les types de documents qu'une organisation peut recevoir, publiez les données de l'entreprise dans la Peppol Directory et gérez l'inscription SMP. Cet article traite du contexte technique et des endpoints API que vous utilisez à cet effet.
Peppol fonctionne avec un modèle à 4 coins : l'expéditeur (C1) envoie via son Access Point (C2) un document à l'Access Point du destinataire (C3), qui le transmet au destinataire (C4). Le routage repose sur deux composants centraux :
C1 Expéditeur
C2 Access Point expéditeur
SML / SMP
C3 Access Point destinataire
C4 Destinataire
SML/SMP lookup
Lorsque vous envoyez une facture via la PSB, celle-ci effectue automatiquement un lookup SML/SMP pour trouver le bon Access Point du destinataire. En tant qu'intégrateur, vous n'avez pas besoin de le faire vous-même.
L'infrastructure Peppol est activement développée. Pour les intégrateurs utilisant l'API PSB, cela n'a aucun impact : la PSB gère automatiquement les lookups SML/SMP. Voici les développements actuels à titre informatif.
Internalisation SML. OpenPeppol reprend la gestion du SML de la Commission européenne (DG DIGIT). La fenêtre de migration a été ouverte le 19 mars 2026. Deux délais distincts s'appliquent : le délai pour les inscriptions SMP est le 31 mai 2026, la période de migration pour l'AP Lookup (résolution DNS) est prolongée jusqu'au 31 août 2026. OpenPeppol discute avec la Commission européenne de la possibilité de prolonger également le délai d'inscription SMP. Pour les intégrateurs API, rien ne change au niveau des endpoints ou des lookups : la PSB gère la migration en interne.
Migration CNAME vers NAPTR. La migration des enregistrements DNS CNAME vers les enregistrements NAPTR pour les lookups SML a été achevée en mars 2026. NAPTR est obligatoire depuis le 1er février 2026. Les anciens enregistrements CNAME ont été supprimés du réseau de test SMK (4 mars 2026) et du réseau de production SML (11 mars 2026). Il s'agit d'un changement DNS interne dans l'infrastructure Peppol. La PSB utilise déjà NAPTR et aucun ajustement n'est nécessaire dans votre intégration.
Migration PKI G3. OpenPeppol prépare la transition des certificats PKI Generation 2 (G2) vers Generation 3 (G3). Les certificats G3 sont utilisés pour la communication mutuelle entre Access Points. Le Peppol Testbed prend en charge les certificats G2 et G3 depuis mars 2026, permettant aux Service Providers de tester en avance. Aucune date de transition obligatoire n'a encore été publiée. Pour les intégrateurs API, rien ne change : la PSB gère le renouvellement des certificats en interne.
Peppol prend en charge les types de documents logistiques en plus des factures via la spécification Peppol Logistics. La version 1.2 est obligatoire depuis le 16 mars 2026. La version 1.3 est obligatoire depuis le 24 août 2026.
Documents logistiques pris en charge :
Nouvelles fonctionnalités dans la version 1.3 :
La version 1.3 traite les RFC LLC-27 à LLC-35, y compris l'alignement ItemInstance, les mises à jour hors facturation et les codes de sous-traitement pour les déchets.
Lors de l'inscription d'une party dans le SMP eConnect, vous déterminez via les capabilities quels types de documents cette party peut recevoir. Chaque capability a trois états possibles :
onoffinheritedLa valeur recommandée pour les nouvelles inscriptions est inherited, sauf si une party doit spécifiquement s'écarter du standard.
invoicesselfbillinginvoice_bisv2reviewsinvoiceResponseordersorderOnlyorderAdvancedorderResponseorderResponseAdvancedLes capabilities sont configurées via l'endpoint Peppol config :
PUT /api/v1/peppol/config/party/{partyId}
Dans le corps de la requête, indiquez l'état souhaité pour chaque capability. Un exemple :
{
"capabilities": {
"invoices": "on",
"selfbilling": "inherited",
"invoiceResponse": "on",
"orderOnly": "on",
"orderAdvanced": "off"
}
}
La Peppol Directory est le registre public de tous les participants Peppol. En publiant une businessCard, une party devient consultable dans la directory. La businessCard contient :
La businessCard est publiée via l'endpoint Enrollment ou via la configuration SMP. Après publication, l'organisation est consultable sur directory.peppol.eu.
L'API PSB ne déduit aucun champ d'un registre du commerce lié. Quel que soit le schéma d'identifiant (KvK 0106, TVA 9944, OIN 0190, GLN 0088 ou un autre), les champs names et address avec code pays doivent être présents explicitement dans la charge utile. Exemple d'une businessCard correctement configurée :
"businessCard": {
"names": {
"value": "eVerbinding, eConnect",
"state": "on",
"description": "Business names."
},
"address": {
"value": "Pelmolenlaan 16A, 3447 GW, Woerden, NL",
"state": "on",
"description": "Geographic information."
},
"emailAddress": {
"value": "techsupport@econnect.eu",
"state": "on",
"description": "Technical contact"
},
"state": "on"
}
Le code pays (dans l'exemple ci-dessus NL à la fin du champ address) doit être explicitement inclus.
Both name(s) and country code are required when adding a business cardCe message d'erreur est sans ambiguïté sur le plan diagnostique : la charge utile soumise ne contient pas names, ou le champ address ne comporte pas de code pays. La correction consiste toujours à ajouter ces champs explicitement dans la charge utile de la businessCard, et non à modifier un autre niveau (party, identifiant, capacités SMP). Le message apparaît en pratique relativement souvent lors de l'intégration GLN (0088), car les partenaires d'intégration GLN utilisent moins souvent un modèle qui transmet ces champs par défaut. La PSB ne présente pas de comportement différent pour GLN par rapport aux autres schémas.
La vérification préalable qu'un destinataire est joignable sur Peppol s'effectue par type de document et via un endpoint de lookup avancé :
POST /api/v1/{partyId}/salesInvoice/queryRecipientParty["0106:..."] ou { "partyIds": [...], "metaAttributes": {...} } ; paramètres optionnels ?preferredDocumentTypeId, ?includeOptionsPOST /api/v1/{partyId}/purchaseOrder/queryRecipientParty?documentFamily=OrderGET /api/v1/peppol/deliveryOption?partyIds=...&documentFamily=...&isCredit=...partyId, documentTypeId, processId, protocol (As2/As4), url, certificateLa réponse montre les canaux disponibles, l'Access Point sélectionné et les types de documents pris en charge. Utilisez ces endpoints pour valider en amont si un envoi aboutira. Ils sont illimités dans toutes les formules (détection/discovery proactive des routes).
Remarque: en cas de désaccord SML/SMP sur l'endpoint
deliveryOption, l'appel n'échoue pas immédiatement. Il n'y a pas de gestion fail-fast en production: l'appel continue et ne retourne un timeout qu'après environ 30 secondes. Tenez-en compte dans la gestion des erreurs de votre intégration.
Dans le réseau Peppol, un participantId dans le SML pointe vers une seule SMP. Via un enregistrement Redirect dans la SMP, des combinaisons spécifiques de type de document et d'identifiant de processus peuvent être redirigées vers une SMP secondaire. Peppol ne prend en charge qu'un seul niveau de redirection : une cible de redirection ne peut pas elle-même contenir une redirection.
Sources alternatives pour les lookups SMP : peppolautoriteit.nl/discover (NPa), peppol.helger.com et directory.peppol.eu (incomplet).
Chaque party dans le SMP est identifiée via un identifiant avec un schemeID. Les schémas les plus couramment utilisés :
01060106:1234567801900190:0000000123456789000099449944:NL123456789B010208BE:EN0208:01234567899925BE:VAT9925:BE0835689642 (également BE1xxxxxxxxx est valide depuis 2025)00880088:1234567890123L'API PSB accepte aussi bien le schemeID numérique que le code lettré : 9925:BE0835689642 est équivalent à BE:VAT:BE0835689642. Avec les outils de recherche externes (comme le SMP lookup), les schemeIDs numériques officiels doivent être utilisés.
Une party peut avoir plusieurs identifiants, mais chaque facture ne peut contenir qu'un seul EndpointID.
En Belgique, deux types d'identifiants sont utilisés pour Peppol. Le numéro d'entreprise (KBO, schemeID 0208) est le numéro d'identification principal et obligatoire pour la réception Peppol. L'inscription sur le numéro de TVA (schemeID 9925) est facultative, ce qui fait que la recherche d'une organisation belge par numéro d'entreprise aboutit plus souvent que par numéro de TVA.
Le numéro d'entreprise se déduit du numéro de TVA en supprimant le préfixe du code pays (BE). Par exemple : le numéro de TVA BE0835689642 correspond au numéro d'entreprise 0835689642.
Lors de l'envoi d'un document, la PSB extrait l'identifiant Peppol de l'élément EndpointID dans le XML. Cet élément détermine vers quel destinataire le document est acheminé. Si l'EndpointID est absent ou renseigné de manière incorrecte, le document n'est pas valide et reçoit le statut InvoiceSentError.
Un XML incorrect n'est pas automatiquement réessayé. La correction incombe au système source (le logiciel qui génère la facture), et non à la PSB. Vérifiez au préalable via queryRecipientParty si le destinataire est joignable sur le réseau Peppol.
Règle de validation NLCIUS qui exige que le schemeID du CompanyID ait la valeur 0190 (OIN) lorsque le destinataire est une partie publique. Sur la plateforme, l'identifiant d'organisation et "Envoyer via" doivent utiliser le même type d'identifiant. Un écart entraîne une erreur de validation sur le document.
Lorsqu'un fournisseur indique qu'une facture a été livrée à eConnect en tant qu'Access Point, mais que le destinataire dit n'avoir rien reçu, le diagnostic côté destinataire passe par le returnedMessageId.
Le returnedMessageId est un identifiant créé par eConnect au moment où l'Access Point accepte ou rejette un document au niveau AS4. Il a en général la forme GUID@econnect.eu. Avec cet identifiant, le support peut retrouver la facture dans le système et suivre le parcours de traitement.
Causes les plus fréquentes d'un document considéré comme "livré" par l'AP émetteur, mais qui n'atteint pas le destinataire :
Parcours support : avec le returnedMessageId, le support retrouve presque tous les documents via la Management API. Si la recherche échoue, le support fait appel à TechSupport.
Avec on vous activez explicitement un type de document pour une party donnée, avec off vous le désactivez explicitement. La valeur inherited signifie que la party reprend la configuration standard de l'organisation. Pour les nouvelles inscriptions, inherited est la valeur recommandée, sauf si une party doit s'écarter spécifiquement.
Non. La PSB effectue automatiquement les lookups SML/SMP lors de l'envoi de documents. En tant qu'intégrateur, vous n'avez pas d'interaction directe avec le SML ou la SMP. Les changements d'infrastructure (migration CNAME vers NAPTR ou insourcing du SML) ne modifient pas non plus votre intégration.
Une businessCard n'est pas obligatoire, mais recommandée. Sans businessCard, la party reste joignable via Peppol (l'inscription SMP est active), mais introuvable dans le Peppol Directory sur directory.peppol.eu. Publiez une businessCard pour accroître la visibilité de votre organisation.
L'API PSB ne déduit aucune valeur d'un registre du commerce lié. Quel que soit le schéma d'identifiant (chambre de commerce, TVA, OIN, GLN), vous devez transmettre explicitement names et une address avec code pays à chaque publication de businessCard. Le message indique toujours un champ names manquant ou une address sans code pays. La correction consiste à compléter ces champs dans la charge utile businessCard ; des changements au niveau party, identifiant ou capability SMP ne résolvent pas l'erreur.
Vous souhaitez automatiser le processus complet d'inscription ? Consultez l'article sur l'Enrollment API, qui permet de configurer l'inscription, les capabilities et les hooks en un seul appel API.
Consulter les endpoints SMP