Developers
An API your customers can actually build on.
Scoped service accounts, a REST API for the whole invoice lifecycle, and signed webhooks with a delivery log. This page is an overview, not the reference. The full OpenAPI spec ships with the platform.
Authentication
Service accounts, not shared passwords.
Each customer issues their own credentials from their own console, scopes them to what the integration actually does, and revokes them without involving you.
OAuth2 client credentials
Exchange a client id and secret for a short-lived access token. No interactive login in a server-to-server integration.
Scoped per token
A token that only reads invoices cannot send one. Scopes are checked at the edge, not inside business logic.
Sandbox or live
A sandbox token behaves identically, with real validation, real webhooks and real status transitions, but never touches the network.
The API
The endpoints an integration actually uses.
Everything is tenant-scoped by the token, so an integration never passes a tenant id and cannot address another one.
Exchange a service-account client id and secret for a scoped access token.
Create an invoice document. Returns it as a draft with an id.
Run PINT-AE validation without sending. Returns the failing rules and the fields behind them.
Submit to the network. Returns immediately; progress arrives by webhook.
The full pipeline timeline for one document, stage by stage.
Documents received over the network for this participant.
Validation is deliberately a separate call from sending. An integration should be able to ask “would this be accepted?” without committing to an exchange, and a finance team should be able to fix an invoice before it leaves rather than chase a rejection afterwards.
Webhooks
Delivery you can audit and replay.
Invoice exchange is asynchronous. Polling for status at scale is how integrations get rate-limited, so status is pushed.
Events
- invoice.status_changed
- invoice.validation_failed
- document.received
- peppol.onboarding.completed
- peppol.onboarding.failed
How delivery behaves
- HMAC-signed with a timestamp, so a replayed request is detectable
- Retried on exponential backoff with jitter, then dead-lettered
- At-least-once, with a stable event id so you can dedupe
- Every attempt logged, with status code, response and a replay button
The delivery log matters more than it sounds. When a customer says “we never got that webhook”, the answer should be a timestamped record of the attempt and the status code their endpoint returned, not a shrug.
Try it
Read the spec inside a live environment.
The API reference is served from the platform itself, so it always matches the version you are running. Get an environment and the docs come with it.