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 :
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 en member review jusqu'au 15 avril 2026, avec une publication prévue le 18 mai 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.
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.
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