SMP-capabilities, Peppol Directory en businessCard configureren via de PSB API.
De PSB is een gecertificeerd Peppol Access Point én SMP (Service Metadata Publisher). Via de API configureer je welke documenttypes een organisatie kan ontvangen, publiceer je bedrijfsgegevens in de Peppol Directory en beheer je de SMP-registratie. Dit artikel behandelt de technische achtergrond en de API-endpoints die je hiervoor gebruikt.
Peppol werkt met een 4-corner model: de verzender (C1) stuurt via zijn Access Point (C2) een document naar het Access Point van de ontvanger (C3), dat het doorgeeft aan de ontvanger (C4). De routering verloopt via twee centrale componenten:
Wanneer je via de PSB een factuur verstuurt, voert de PSB automatisch een SML/SMP-lookup uit om het juiste Access Point van de ontvanger te vinden. Je hoeft dit als integrator niet zelf te doen.
De Peppol-infrastructuur wordt actief doorontwikkeld. Voor integrators die de PSB API gebruiken heeft dit geen gevolgen: de PSB handelt SML/SMP-lookups automatisch af. Hieronder staan de actuele ontwikkelingen ter informatie.
SML insourcing. OpenPeppol neemt het beheer van de SML over van de Europese Commissie (DG DIGIT). Het migratievenster is geopend op 19 maart 2026. Er gelden twee aparte deadlines: de deadline voor SMP-registraties is 31 mei 2026, de migratieperiode voor AP Lookup (DNS-resolutie) is verlengd tot 31 augustus 2026. OpenPeppol bespreekt met de Europese Commissie of ook de SMP-registratiedeadline verlengd kan worden. Voor API-integrators verandert er niets aan endpoints of lookups: de PSB handelt de migratie intern af.
CNAME-naar-NAPTR-migratie. De migratie van DNS CNAME-records naar NAPTR-records voor SML-lookups is in maart 2026 afgerond. NAPTR is verplicht sinds 1 februari 2026. De oude CNAME-records zijn verwijderd uit het SMK-testnetwerk (4 maart 2026) en het SML-productienetwerk (11 maart 2026). Dit is een interne DNS-wijziging in de Peppol-infrastructuur. De PSB gebruikt al NAPTR en er zijn geen aanpassingen nodig aan je integratie.
PKI G3-migratie. OpenPeppol bereidt de overgang voor van PKI Generation 2 (G2) naar Generation 3 (G3) certificaten. G3-certificaten worden gebruikt voor de onderlinge communicatie tussen Access Points. Het Peppol Testbed ondersteunt sinds maart 2026 zowel G2- als G3-certificaten, zodat Service Providers alvast kunnen testen. Er is nog geen verplichte overgangsdatum gepubliceerd. Voor API-integrators verandert er niets: de PSB handelt de certificaatvernieuwing intern af.
Peppol ondersteunt naast facturen ook logistieke documenttypes via de Peppol Logistics-specificatie. Versie 1.2 is verplicht sinds 16 maart 2026. Release 1.3 staat tot 15 april 2026 in member review, met publicatie verwacht op 18 mei 2026.
Ondersteunde logistieke documenten:
Nieuwe functies in release 1.3:
Release 1.3 verwerkt RFC's LLC-27 t/m LLC-35, waaronder ItemInstance-alignment, updates voor niet-facturatie en sub-treatment codes voor afval.
Bij het registreren van een party in de eConnect SMP bepaal je via capabilities welke documenttypes die party kan ontvangen. Elke capability heeft drie mogelijke states:
onoffinheritedDe aanbevolen waarde voor nieuwe registraties is inherited, tenzij een party specifiek moet afwijken van de standaard.
invoicesselfbillinginvoice_bisv2reviewsinvoiceResponseordersorderOnlyorderAdvancedorderResponseorderResponseAdvancedCapabilities worden geconfigureerd via het Peppol-config endpoint:
PUT /api/v1/peppol/config/party/{partyId}
In de request body geef je per capability de gewenste state mee. Een voorbeeld:
{
"capabilities": {
"invoices": "on",
"selfbilling": "inherited",
"invoiceResponse": "on",
"orderOnly": "on",
"orderAdvanced": "off"
}
}
De Peppol Directory is het openbare register van alle Peppol-deelnemers. Door een businessCard te publiceren, wordt een party vindbaar in de directory. De businessCard bevat:
De businessCard wordt gepubliceerd via het Enrollment endpoint of via de SMP-configuratie. Na publicatie is de organisatie vindbaar op directory.peppol.eu.
De PSB-API leidt geen velden af uit een gekoppeld handelsregister. Ongeacht het identifier-scheme (KvK 0106, BTW 9944, OIN 0190, GLN 0088 of een ander) moeten zowel names als een address met landcode expliciet in de payload aanwezig zijn. Een voorbeeld van een correct geconfigureerde businessCard:
"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": "[email protected]",
"state": "on",
"description": "Technical contact"
},
"state": "on"
}
De landcode (in het voorbeeld hierboven NL aan het einde van het address-veld) moet expliciet zijn opgenomen.
Both name(s) and country code are required when adding a business cardDeze foutmelding is diagnostisch eenduidig: de aangeboden payload mist names, of het address bevat geen landcode. De fix is altijd het expliciet aanvullen van die velden in de businessCard-payload, niet een wijziging op een ander niveau (party, identifier, SMP-capabilities). De melding komt in de praktijk relatief vaak voor bij GLN-integratie (0088), omdat GLN-integratiepartners minder vaak een template gebruiken die deze velden standaard meestuurt. PSB vertoont voor GLN geen ander gedrag dan voor andere schemes.
Vooraf controleren of een ontvanger bereikbaar is op Peppol gebeurt per documenttype én via een advanced lookup-endpoint:
POST /api/v1/{partyId}/salesInvoice/queryRecipientParty["0106:..."] of { "partyIds": [...], "metaAttributes": {...} }; optionele ?preferredDocumentTypeId, ?includeOptionsPOST /api/v1/{partyId}/purchaseOrder/queryRecipientParty?documentFamily=OrderGET /api/v1/peppol/deliveryOption?partyIds=...&documentFamily=...&isCredit=...partyId, documentTypeId, processId, protocol (As2/As4), url, certificateDe response toont de beschikbare kanalen, het geselecteerde Access Point en de ondersteunde documenttypes. Gebruik deze endpoints om vooraf te valideren of een verzending zal slagen. Ze zijn onbeperkt beschikbaar in alle pakketten (proactieve routedetectie/discovery).
Elke party in de SMP wordt geïdentificeerd via een identifier met een schemeID. De meestgebruikte schemas:
01060106:1234567801900190:0000000123456789000099449944:NL123456789B010208BE:EN0208:01234567899925BE:VAT9925:BE0835689642 (ook BE1xxxxxxxxx is geldig sinds 2025)00880088:1234567890123De PSB API accepteert zowel het numerieke schemeID als de lettercode: 9925:BE0835689642 is equivalent aan BE:VAT:BE0835689642. Bij externe lookuptools (zoals de SMP-lookup) moeten de officiële numerieke schemeIDs worden gebruikt.
Een party kan meerdere identifiers hebben, maar elke factuur mag slechts één EndpointID bevatten.
In België worden twee identifiertypen gebruikt voor Peppol. Het ondernemingsnummer (KBO, schemeID 0208) is het primaire identificatienummer en verplicht voor Peppol-ontvangst. Registratie op BTW-nummer (schemeID 9925) is optioneel, waardoor het opzoeken van een Belgische organisatie via het ondernemingsnummer vaker succesvol is dan via het BTW-nummer.
Het ondernemingsnummer is af te leiden uit het BTW-nummer door de landcode-prefix (BE) te verwijderen. Bijvoorbeeld: BTW-nummer BE0835689642 correspondeert met ondernemingsnummer 0835689642.
Bij het verzenden van een document haalt de PSB het Peppol ID uit het EndpointID-element in de XML. Dit element bepaalt naar welke ontvanger het document wordt gerouteerd. Als het EndpointID ontbreekt of onjuist is ingevuld, is het document niet valide en krijgt het de status InvoiceSentError.
Een foutieve XML wordt niet automatisch opnieuw geprobeerd. De correctie ligt bij het bronsysteem (het softwarepakket dat de factuur genereert), niet bij de PSB. Controleer vooraf via queryRecipientParty of de ontvanger bereikbaar is op het Peppol-netwerk.
::e-accordion-item{value="item-1" header="Wat is het verschil tussen de capability-states "on", "off" en "inherited"?"}
Met on schakel je een documenttype expliciet in voor een specifieke party, met off schakel je het expliciet uit. De waarde inherited betekent dat de party de standaardconfiguratie van de organisatie overneemt. Voor nieuwe registraties is inherited de aanbevolen waarde, tenzij een party specifiek moet afwijken.
::
Nee, de PSB handelt SML/SMP-lookups automatisch af bij het verzenden van documenten. Je hoeft als integrator geen directe interactie met de SML of SMP te hebben. Ook bij infrastructuurwijzigingen (zoals de CNAME-naar-NAPTR-migratie of SML insourcing) verandert er niets aan je integratie.
Een businessCard is niet verplicht, maar wel aanbevolen. Zonder businessCard is de party weliswaar bereikbaar via Peppol (de SMP-registratie is actief), maar niet vindbaar in de Peppol Directory op directory.peppol.eu. Publiceer een businessCard om de zichtbaarheid van je organisatie te vergroten.
De PSB-API leidt geen waarden af uit een gekoppeld handelsregister. Ongeacht het identifier-scheme (KvK, BTW, OIN, GLN) moet je bij elke businessCard-publicatie zowel names als een address met landcode expliciet in de payload meesturen. De foutmelding wijst altijd op een ontbrekend names-veld of een address zonder landcode. De fix is het aanvullen van die velden in de businessCard-payload; aanpassingen op party-, identifier- of SMP-capability-niveau lossen het niet op.
Wil je het volledige registratieproces automatiseren? Lees het artikel over de Enrollment API, waarmee je registratie, capabilities en hooks in één API-call configureert.
Bekijk de SMP-endpoints