L’intégration avec l’entrepôt, l’ERP ou le portail de transport n’est pas conçue pour vérifier toutes les quelques secondes si quelque chose a changé dans le contrôle des créneaux horaires. Les webhooks sortants transmettent un événement au fur et à mesure qu’il se produit, tout en gardant un résultat clair de chaque tentative de livraison.

De l’événement à la livraison sans interrogation

Lorsqu’une réservation ou une commande change, le TSC crée un événement et sélectionne les abonnements webhook actifs qui suivent ce type. Chaque abonnement reçoit un JSON versionné via HTTP POST vers son adresse de destination.

TSC détecte le changement et crée un événement unique.
Les abonnements actifs sont comparés à son type.
Une livraison distincte sera créée pour chaque commande correspondante.
La réponse du système cible détermine l’état résultant ou la tentative suivante.

Le traitement est piloté par des événements et se déroule de manière asynchrone. Le système connecté n’a pas à alourdir l’API avec des requêtes fréquentes et peut répondre peu après le changement effectif.

Flux de livraison d’un webhook sortant, de l’événement TSC au HTTP POST signé, puis à Delivered, Failed ou DeadLetter et au Resend manuel

Le journal de livraison remplace les suppositions

L’administrateur peut voir la livraison en un seul endroit et les filtrer par abonnement webhook et statut. Pour chaque enregistrement, il y a un type d’événement, un nombre de tentatives, un dernier statut HTTP, une dernière tentative, ainsi qu’une brève information d’erreur.

Statut	Qu’est-ce que cela signifie ?
Pending	La livraison attend dans la file pour la première ou la prochaine tentative.
Delivered	Le système cible a renvoyé une réponse HTTP réussie.
Failed	La dernière tentative s’est terminée par une erreur temporaire et sera répétée.
DeadLetter	Les tentatives automatiques ont pris fin ou la réponse ne doit pas être répétée automatiquement.

Que se passe-t-il lorsque le système cible n’est pas disponible

Les erreurs réseau, les réponses HTTP 429 et les erreurs serveur 5xx se répètent à intervalles croissants, dans un maximum de cinq tentatives. Les erreurs courantes des clients 4xx sauf 429 iront directement à l’état DeadLetter, car la tentative automatique suivante se terminerait généralement la même.

Après la réparation du système récepteur, l’utilisateur autorisé peut utiliser Resend. TSC réinitialise le nombre de tentatives, supprime la dernière erreur et renvoie la livraison à la file d’attente. Ainsi, il n’est pas nécessaire de rappeler l’événement métier original.

Événements correspondant au trafic réel

Le catalogue ne se termine pas par une création, une modification ou une suppression génériques. Une intégration peut aussi supprimer des points spécifiques du cycle de vie de réservation et de commande, comme reservation.pendingLivrereservation.vehicle.platechangedreservation.markedasarrivalreservation.approval.approvedreservation.processingstartedreservation.markedasdeparted, A ou order.confirmedA.

L’abonnement ne sélectionne que les événements dont il a besoin. Le système cible n’a pas à déduire rétroactivement du changement général ce qui s’est réellement passé dans l’opération.

Messages signés et traitement sécurisé

L’adresse webhook utilise HTTPS. TSC envoie un enveloppeur JSON avec schemaVersiondes champs, occurredAteventIdeventtenantIdet data. Le corps de la requête est signé avec HMAC-SHA256, et le destinataire reçoit une signature dans l’en-tête X-TSC-Signature accompagnée d’un horodatage.X-TSC-Timestamp

Le système récepteur doit valider la signature et l’horodatage, les traiter eventId de manière idempotente, et ne renvoyer un état 2xx réussi qu’après avoir reçu le message en toute sécurité. Le secret peut être modifié lorsque la sécurité est modifiée.

Qu’apporte-t-il aux opérations d’intégration

Moins de requêtes de sondage et moins de fardeau des deux côtés de l’intégration.
statut lisible de chaque livraison sans chercher dans plusieurs outils de journalisation,
Récupération automatique après des erreurs temporaires
Tentative manuelle contrôlée après la réparation du système cible.
origine vérifiable et intégrité de chaque message.

Le résultat est non seulement une transmission plus rapide des événements, mais aussi une intégration opérationnellement prévisible : l’équipe peut voir ce qui a été livré, ce qui attend la prochaine tentative et ce qui nécessite une intervention.

Souhaitez-vous connecter TSC à un ERP, un WMS ou votre propre plateforme d’intégration ? Parcourez les options d’intégration ou décrivez-nous votre scénario.