A document you submit via the PSB passes through a fixed sequence of processing phases — from submission to confirmed delivery or definitive failure. At each transition point, the PSB publishes a status message that you can retrieve via the status API or capture via a webhook.

This article describes the flow in detail, which status codes and topics the PSB publishes, how to query the status of a document and what happens when delivery or webhook notification fails.

Submit → Validate → Transform → Route → Acknowledge → Delivered
                                                   ↘ Failed

Submit can be initiated from various channels — REST upload, mailfrom hook, SFTP pull, Office 365 or another hook type. From Submit onwards, the flow is identical for every channel.

The PSB publishes the following canonical statuses via topics and the status API:

Additional fine-grained topics such as InvoiceSentRetry, InvoiceSentError and MessageLevelStatusReceived are available for monitoring via webhooks.

The current status of a document can be retrieved via a status endpoint per document type:

• GET /api/v1/{partyId}/salesInvoice/{documentId}/status
• GET /api/v1/{partyId}/purchaseInvoice/{documentId}/status

The response contains the current status, the timestamp of the last change and, in case of an error, an error code with description. Via a list endpoint per document type you can filter outstanding documents by status, period and (where relevant) recipient.

For real-time integration, webhook routing is preferred over polling. Subscribe to the relevant topics to receive direct notifications:

See Setting up webhooks for configuration, payload structure and HMAC signature.

If a delivery attempt fails due to an error on the receiving side (e.g. 5xx from a Peppol Access Point), the PSB automatically resumes delivery with exponential backoff.

With each delivery attempt, the PSB publishes a {DocumentType}SentRetry topic. After definitive failure, {DocumentType}SentError follows. If you receive an InvoiceSentError or OrderSentError, contact the recipient or escalate via eConnect Support.

Tip: subscribe to InvoiceSentRetry and InvoiceSentError via a webhook so you detect delivery problems immediately.

The retry policy for webhook delivery — notifications to your own endpoint — is separate from the delivery retry policy.

The PSB expects a 2xx response from your endpoint within 100 seconds. Process incoming webhooks as quickly as possible: confirm receipt with 200 OK and do heavy processing asynchronously in a background process.

Optionally: add the query parameter noRetryCodes to exclude specific HTTP codes from retry (e.g. ?noRetryCodes=400,401,403). Set up a mail hook or secondary webhook on HookSentError for operational monitoring.

Note: after approximately 6 days (137 hours) without successful delivery, the PSB stops retrying. Missed events can be retrieved via the batch endpoint. See Batch hooks.

Submit endpoints support idempotency via the X-EConnect-DocumentId header. On a duplicate submission, the PSB returns HTTP 409 Conflict. This ensures re-requests — e.g. after a network error — are never processed twice. See Idempotency for the full explanation.