Delivery is now Peppol-only — contact emails are no longer a silent fallback

Until today, when a recipient could not be reached on the Peppol network, the contact email on the invoice (to.email) could silently become the delivery channel: the document was sent as an email attachment and still reported delivered. That status was technically true — and completely misleading for a product whose job is Peppol delivery.

This is now fixed. getpeppr is Peppol-only.

What changed

• to.email is contact data, nothing more. It still appears on the invoice as the buyer's contact email (EN 16931 BT-43), but it is never passed to our provider as a delivery route. No document will ever be delivered by plain email again.
• to.peppolId is now required on POST /v1/invoices. Requests without it are rejected with an explicit 422 and an actionable message. The SDK already enforced this client-side; the API now enforces it for everyone, including raw HTTP integrations.
• Unreachable recipients fail fast and loud. If the recipient cannot be found on the network, the document ends in a clear failure state instead of a false delivered. Use the Peppol directory search or the x-validate-recipient header to check recipients before sending.

Why

A delivered status must mean exactly one thing: the document reached the recipient's access point on the Peppol network. This also prepares the ground for France's September 2026 mandate, where the transmission channel itself is a regulatory requirement.

No production traffic relied on the email fallback — this change affects new sends only. In sandbox, remember that real-world companies are not reachable on the test network: use the test buyer from the quickstart to see a full delivery lifecycle.