Skip to content
einvoicing.dev

Docs · How it works

Participants

Before sending anything, you need to know whether the other side is on the network and what it accepts. That is one request.

How a business is addressed

A participant identifier is a scheme and a value: 9932:GB123456789. The scheme says what kind of identifier it is — 9932 is a UK VAT number, 0088 a GLN — and the value is the identifier itself. There is no Companies House scheme, so for a UK business the VAT number is usually the address.

Registrations exist both with and without the GB prefix, and Peppol treats them as two different participants. Both forms are tried for 9932, and the response says which one is actually registered. Identifiers are matched case-insensitively and come back lower-cased, because that is how Peppol hashes them.

Not registered is an answer

A participant that is not on the network returns 200 with registered: false, not a 404. Absence from a public directory is a fact about the world, not a missing resource, and your code should be able to tell the two apart.

Look up
curl https://api.einvoicing.dev/v1/participants/<participant_id> \  -H "Authorization: Bearer $EINVOICING_API_KEY"

Where the answer comes from

  • The SML is the authoritative source: a DNS lookup that says where a participant's metadata lives.
  • The SMP is that metadata: which document types the participant accepts, and through which Access Point.
  • The Peppol Directory is optional for participants, so directoryis null for many businesses that are registered perfectly well. Never treat that as "not found".

Results are cached for up to five minutes, and checked_at says when the network was last asked.

Look up a Peppol participant

The operation: the identifier format, the response and its errors.

The four-corner model

Why an address and an Access Point are different things.