Flux de document et messages de statut

Comment un document parcourt les six phases du PSB : de Submit à Delivered ou Failed, avec messages de statut, webhooks et politique de retry.

Un document envoyé via le PSB suit une séquence fixe de phases de traitement — de la soumission à la livraison confirmée ou à l'échec définitif. À chaque point de transition, le PSB publie un message de statut que vous pouvez récupérer via l'API de statut ou capturer via un webhook.

Cet article décrit le flux en détail, les codes de statut et topics publiés par le PSB, comment interroger le statut d'un document et ce qui se passe en cas d'échec de livraison ou de notification webhook.

Les six phases d'un document
Submit → Validate → Transform → Route → Acknowledge → Delivered
                                                   ↘ Failed
PhaseCe qui se passeTopics typiquesSubmitLe document a été soumis via l'API, un hook mailfrom, SFTP pull ou une autre méthode entrante.PendingValidateLe PSB valide le document selon le schéma et les règles métier (ex. NLCIUS, Peppol BIS Billing, DICO).Validated, *ReceivedError en cas d'erreurTransformConversion de format optionnelle via le moteur Transform (ex. UBL vers CII, PDF vers UBL via IDR). Étape interne.(interne, pas de topic séparé)RouteLe PSB détermine la destination : Peppol, e-mail, SFTP ou un autre canal ou combinaison.RoutedAcknowledgeConfirmation du point d'accès ou canal récepteur.AcknowledgedDelivered / FailedLa livraison est confirmée, ou définitivement échouée après épuisement de toutes les tentatives.*Sent, *SentError
Codes de statut
StatutSignificationStatut final ?PendingSoumis, validation pas encore démarréeNonValidatedValidation réussieNonRoutedDestination déterminée, prêt pour la livraisonNonDeliveredLivraison confirmée par le destinataire ou le canalOuiRejectedRejeté par le destinataire (ex. via MLS Reject)OuiFailedLivraison définitivement échouée après toutes les tentativesOui
Politique de retry pour la livraison de documents

Si une tentative de livraison échoue, le PSB reprend automatiquement la livraison avec un backoff exponentiel.

ParamètreValeurNombre maximum de tentatives8Durée totale de retry~3 jours (environ 72 heures) dès la première tentativeCodes retryables5xx et 429Non retryable4xx (sauf 429) — *SentError immédiatBackoffExponentiel (temps d'attente croissant par tentative)
Politique de retry pour la livraison des webhooks
ParamètreValeurNombre maximum de tentatives12Durée totale de retry~6 jours (environ 137 heures) dès la première tentativeBackoffExponentielTimeout par tentative100 secondesÉvénement par tentativeHookSentRetryÉvénement après échec définitifHookSentError

Remarque : après environ 6 jours (137 heures) sans livraison réussie, le PSB arrête les tentatives. Les événements manqués peuvent être récupérés via l'endpoint batch.

Questions fréquentes
Comment suivre le statut d'un document envoyé ?

Vous avez deux options. Via l'API de statut (GET …/salesInvoice/{documentId}/status) vous récupérez le statut actuel. Pour le monitoring en temps réel, configurez des webhooks sur les topics pertinents comme InvoiceSent, InvoiceSentRetry et InvoiceSentError.

Combien de temps le PSB tente-t-il de livrer un document ?

Le PSB réessaie la livraison automatiquement jusqu'à 8 fois sur environ 3 jours (72 heures). Après échec définitif, {DocumentType}SentError suit et une action manuelle est nécessaire.

Combien de temps le PSB tente-t-il de livrer un webhook ?

Le PSB tente de livrer une notification webhook jusqu'à 12 fois, réparties sur environ 6 jours (137 heures). Après échec définitif, l'événement HookSentError suit.

Voir la documentation API interactive