Now that delivery is Peppol-only, a recipient that cannot be found on the
network ends the send in the no_action status — "Not Deliverable" in the
dashboard. Until today only the dashboard showed it: webhook integrations,
SDK polling and CI pipelines had no signal at all.
What changed
- New webhook event
invoice.undeliverable. Fired when our provider reports that no receiving capability exists for the recipient. The payload has the same shape as the otherinvoice.*events and carriesstatus: "no_action". Wildcard (*) subscriptions receive it automatically — add it to explicit event filters if you subscribe per-event. - SDK:
waitFor()fails fast.no_actionis now a terminal failure alongsidefailedandrejected: the promise rejects immediately instead of polling until the timeout. Waiting forno_actionas an explicit target still resolves. - CLI:
getpeppr send --watchexits non-zero. A watch ending onno_actionnow exits1, so scripts and CI pipelines catch undeliverable invoices instead of reporting success.
Anything breaking?
No runtime breaking change. The /v1 status vocabulary is untouched —
no_action already existed as a document status. Endpoints subscribed to
specific events keep receiving exactly what they subscribed to; only wildcard
(*) subscribers start receiving the new event. One note for TypeScript
users: the SDK's WebhookEventType union gains a member, so an exhaustive
switch over it needs a new case "invoice.undeliverable" when you upgrade.
To check a recipient before sending, use the directory
search or the x-validate-recipient header.