WEBHOOKS
Webhooks
Recevez les événements en temps réel de Superroute — commandes, changements de statut, mises à jour de suivi. Avec charges utiles signées, nouvelles tentatives automatiques et débogueur intégré.
WEBHOOKS
Recevez les événements en temps réel de Superroute — commandes, changements de statut, mises à jour de suivi. Avec charges utiles signées, nouvelles tentatives automatiques et débogueur intégré.
Un webhook est une requête HTTP POST que Superroute envoie à une URL que vous configurez chaque fois qu'un événement se produit — création de commande, livraison terminée, événement de suivi enregistré. Vous construisez un point de réception, nous y livrons l'événement.
Les événements sont mis en file d'attente et envoyés de façon asynchrone. Chaque requête porte une signature HMAC-SHA256 pour vérifier son origine. Les livraisons échouées (réponse non 2xx ou timeout) sont réessayées avec backoff exponentiel jusqu'à 5 fois.
Vous configurez un secret partagé sur la page de paramètres. Chaque webhook sortant est signé avec ce secret. Votre récepteur recalcule la signature et compare — si elles correspondent, la charge utile est authentique et non altérée.
Huit types d'événements sortants sont disponibles. Chacun a son propre champ URL sur la page de paramètres — abonnez-vous à n'importe quel sous-ensemble.
Description lisible par machine de tous les événements sortants, avec schémas de charge utile, en-têtes et calendriers de nouvelle tentative (AsyncAPI 3.0) : asyncapi-webhooks.json
Se déclenche à la création d'une commande de livraison locale (Delivery / Pickup / P2P), quel que soit le canal : formulaire web, API REST/GraphQL, synchronisation plateforme e-commerce, règles automatiques, lignes d'import, etc. Exclut les commandes label-service et les autres types non-livraison. Ignoré dans le flux batch lorsque order_create_async_postback_url est également configuré pour le même destinataire. Configurez via order_create_webhook_url.
Exemples de Charge UtileSe déclenche à chaque transition de statut — récupéré, en transit, livré, exception, annulé. Configurez via order_status_change_webhook_url.
Exemples de Charge UtileSe déclenche à chaque événement du cycle de vie d'un colis (informations soumises, début de livraison, livraison réussie, non livré, etc.). Configurez via tracking_event_webhook_url. Les événements « livré » et « ramassé » transportent aussi la preuve de livraison : proof_files et proof_files_detail (file_id, type, url, full_url, URL de téléchargement signée). Les photos téléversées après l’événement arrivent via pod.files_updated. Chaque fichier porte aussi le contexte de son événement : tracking_event_id, tracking_event_status_id, tracking_event_key, service_type (1 = delivery / 2 = pickup) et service_status (1 = success / 2 = failed) ; ils valent null pour les anciens fichiers sans événement enregistré.
Exemples de Charge UtileSe déclenche une fois après le traitement d'un import par lot. La charge contient le tableau des résultats par ligne. Configurez via order_create_async_postback_url.
Exemples de Charge UtileDéclenché quand une photo de livraison ou une signature est ajoutée, remplacée ou supprimée (action : added / updated / removed) — un envoi par fichier, plus besoin d’interroger les pièces jointes. Activé via pod_files_webhook_url. Chaque fichier porte aussi le contexte de son événement : tracking_event_id, tracking_event_status_id, tracking_event_key, service_type (1 = delivery / 2 = pickup) et service_status (1 = success / 2 = failed) ; ils valent null pour les anciens fichiers sans événement enregistré. Lorsqu'un employé remplace une photo ou une signature, ou définit une version archivée comme actuelle, le fichier est envoyé avec action: updated et ne contient que l'image actuelle ; les versions archivées ne sont jamais envoyées.
Exemples de Charge UtileDéclenché quand une commande est supprimée définitivement, afin que votre système puisse refléter la suppression. Activé via order_deleted_webhook_url.
Exemples de Charge UtileDéclenché quand une tentative d'annulation est refusée (par exemple la commande est déjà en cours de livraison), afin que vos équipes puissent surveiller les annulations échouées sans interroger l'API. Activé via order_cancel_failed_webhook_url.
Exemples de Charge UtileDéclenché lorsqu'un siège du tableau des tournées change de titulaire ou que le tableau change d'état — le champ action indique ce qui s'est passé (claimed, standby, pooled, promoted, withdrawn, vetoed, replaced, assigned, awarded, lost, displaced, settled, board_opened, board_closed, board_cancelled). Niveau entreprise uniquement. Abonnement via route_board_webhook_url.
Exemples de Charge UtileUn canal webhook distinct pour les prestataires de livraison tiers intégrés aux consignes intelligentes. Les événements sont livrés au point de terminaison configuré pour votre compte prestataire, et chaque point de terminaison peut s'abonner à n'importe quel sous-ensemble de types d'événements.
Portes Ouvertes — Se déclenche à l'instant où les portes des casiers s'ouvrent pour une tentative de dépôt — que le livreur ait saisi le code d'accès sur l'écran de la consigne ou utilisé l'API d'ouverture à distance — y compris les réouvertures après réaffectation. Le bloc opening liste chaque casier ouvert avec son grid_id, le numéro de porte matériel compartment_number et le pickup_locker_number (numéro d'affichage séquentiel compté de haut en bas par colonne, puis de gauche à droite). Chaque compartiment porte aussi pickup_locker_code — l'étiquette « {shelf_code}-{pickup_locker_number} » vers laquelle le destinataire est dirigé ; null lorsque le compartiment n'a pas de numéro de retrait. La charge utile comporte également pickup_code — le code de retrait du destinataire, attribué dès l'ouverture des portes ; il reste le même code après la confirmation du dépôt par le livreur et ne devient utilisable pour le retrait qu'une fois le dépôt confirmé.
Exemples de Charge UtileDéposé dans la consigne — Déclenché quand un dépôt est confirmé et que les colis sont dans la consigne. La charge utile inclut le code de retrait du destinataire. Chaque compartiment porte aussi pickup_locker_code — l'étiquette « {shelf_code}-{pickup_locker_number} » vers laquelle le destinataire est dirigé ; null lorsque le compartiment n'a pas de numéro de retrait. Pour les portes ouvertes via l'API d'ouverture à distance, la plateforme règle le dépôt dès que la consigne signale toutes les portes ouvertes comme refermées ; l'événement est alors émis sans appel confirm. confirmed_by indique la voie de règlement : courier_terminal, partner_api, door_close, timeout_door_closed ou console.
Exemples de Charge UtileRetiré — Déclenché quand le destinataire a récupéré les colis déposés.
Exemples de Charge UtileÉchec de livraison — Déclenché quand une livraison échoue ; les codes d'échec par colis sont inclus.
Exemples de Charge UtileExpiré — Déclenché quand un code de livraison inutilisé ou un dépôt non retiré dépasse sa date d'expiration.
Exemples de Charge UtileAnnulé — Déclenché quand une livraison est annulée avant son achèvement.
Exemples de Charge UtileRéouverture de correction — Déclenché quand les casiers occupés sont rouverts pendant la fenêtre de correction pour corriger un mauvais placement — depuis l'écran de la consigne ou via l'API. Le bloc correction liste les casiers rouverts. Chaque compartiment porte aussi pickup_locker_code — l'étiquette « {shelf_code}-{pickup_locker_number} » vers laquelle le destinataire est dirigé ; null lorsque le compartiment n'a pas de numéro de retrait.
Exemples de Charge UtileCode de retrait modifié — Se déclenche lorsque le partenaire renouvelle le code de dépôt ou le code de retrait d'une livraison. Le bloc rotation indique quel code a été remplacé, quand, et si la notification au destinataire a été renvoyée — le nouveau code ne transite jamais par un webhook ; il n'est révélé que dans la réponse directe de l'API de renouvellement.
Exemples de Charge UtileColis transporteur distribué — Se déclenche quand un colis transporteur préannoncé, reçu dans un entrepôt, est placé sur un ordre de distribution vers le site désigné par le transporteur. Le bloc data porte le numéro de colis, la référence transporteur et le numéro d'adhérent, l'ordre de distribution (order_id, order_ref, status) et les sites d'origine et de destination. Enregistré uniquement pour les transporteurs disposant d'un compte prestataire.
Exemples de Charge UtileColis transporteur chargé — Se déclenche quand le colis est scanné dans le camion à l'entrepôt d'origine ; distribution.status vaut in_transit et loaded_at est renseigné.
Exemples de Charge UtileColis transporteur livré au site — Se déclenche quand le chauffeur remet l'ordre de distribution sur le site ; distribution.status vaut delivered et delivered_at est renseigné. Le rangement est un événement ultérieur et distinct.
Exemples de Charge UtileColis transporteur rangé au site — Se déclenche quand le colis est rangé sur le site, dans un casier ou sur un rayon ; location porte grid_id, grid_code et shelf_code. La notification de retrait au destinataire part à ce moment.
Exemples de Charge UtileColis transporteur retiré de la distribution — Se déclenche quand le colis est retiré d'un ordre de distribution avant le départ, ou que l'ordre est annulé ; distribution.reason vaut removed ou cancelled. Le colis revient sur la liste de distribution de l'entrepôt.
Exemples de Charge UtileSignature et Vérification: Les webhooks des consignes prestataires utilisent leur propre schéma de signature : X-Webhook-Signature vaut base64(HMAC-SHA256(secret, horodatage + "\n" + id de livraison + "\n" + corps brut)), où l'horodatage et l'id de livraison proviennent des en-têtes X-Webhook-Timestamp et X-Webhook-Delivery-Id. Vérifiez aussi X-Webhook-Content-Digest (SHA-256 du corps) et rejetez les horodatages périmés. X-Webhook-Id reste stable entre les tentatives — utilisez-le pour l'idempotence.
Comment Configurer: Les points de terminaison se gèrent dans Livraison tierce → Consigne prestataire → Paramètres, un point de terminaison par prestataire, avec une liste d'événements sélectionnable. Les livraisons échouées sont retentées avec un backoff exponentiel jusqu'à 7 fois avant mise en file morte ; les événements en file morte peuvent être renvoyés manuellement depuis la page des événements.
Événements sandbox (casiers simulés): Les livraisons créées sur des casiers simulés émettent les mêmes événements webhook qu'en production, signés avec le même secret, afin de développer avec un trafic réaliste. Les événements sandbox sont marqués de trois façons : la charge utile contient "livemode": false, l'event_id commence par PLE-MOCK- et la requête porte l'en-tête X-Webhook-Test: 1. Si une URL sandbox est configurée sur le point de terminaison, les événements sandbox y sont envoyés au lieu de l'URL de production ; sinon ils reviennent vers l'URL de production, toujours marqués. L'interrupteur « Livrer les événements sandbox » arrête complètement la livraison sandbox.
Webhooks de livraison de colis envoyés aux prestataires de livraison tiers (transporteurs). Ils couvrent le cycle de vie des affectations de livraison, de sorte qu'un transporteur n'a plus besoin d'interroger la plateforme à la recherche de nouvelles missions. Cette catégorie est distincte des événements de consigne intelligente ci-dessous : chaque prestataire configure par catégorie un point de terminaison, un secret de signature et un abonnement aux événements indépendants — dans son propre portail prestataire ou via l'opérateur de la plateforme.
Affectation créée — Se déclenche quand une commande est affectée au prestataire — par une règle automatique ou manuellement. La charge utile contient le numéro d'affectation, les identifiants de la commande et les numéros de suivi des colis.
Exemples de Charge UtileColis remis — Se déclenche quand l'entrepôt a physiquement remis au prestataire tous les colis de l'affectation.
Exemples de Charge UtileAffectation annulée — Se déclenche quand la plateforme retire une affectation au prestataire. Le champ reason distingue cancelled (l'affectation a été annulée chez le transporteur), fallback_to_self_delivery (la plateforme a repris la commande en livraison propre) et reassigned (la commande a été transférée à un autre prestataire).
Exemples de Charge UtileLivraison partielle — Se déclenche lorsqu'une partie d'un envoi a été livrée alors que d'autres colis sont encore en cours. Le tableau packages indique le résultat de chaque colis et legs liste les commandes externes enregistrées chez le transporteur — une par colis lorsque le transporteur n'accepte pas les envois multicolis.
Exemples de Charge UtileSignature et Vérification: Les webhooks de livraison tierce utilisent le même schéma de signature que les webhooks des consignes prestataires : X-Webhook-Signature vaut base64(HMAC-SHA256(secret, timestamp + "\n" + delivery id + "\n" + raw body)), le timestamp et le delivery id provenant des en-têtes X-Webhook-Timestamp et X-Webhook-Delivery-Id. Vérifiez aussi X-Webhook-Content-Digest (SHA-256 du corps) et rejetez les horodatages périmés. X-Webhook-Id reste stable entre les tentatives — utilisez-le pour l'idempotence.
Comment Configurer: Les prestataires configurent eux-mêmes ce point de terminaison dans le portail prestataire (Paramètres des webhooks), ou l'opérateur de la plateforme le fait dans Livraison tierce → Prestataires → Webhooks. Un point de terminaison par prestataire avec une liste d'événements sélectionnable. Le secret de signature peut être généré automatiquement ou défini avec une valeur personnalisée, et il est consultable sur la page des paramètres. Les livraisons échouées sont retentées avec un backoff exponentiel jusqu'à 7 fois avant mise en file morte ; les événements en file morte peuvent être renvoyés manuellement. Un événement de test (mock) signé peut être envoyé à tout moment depuis la page des paramètres — les requêtes de test portent l'en-tête X-Webhook-Test: 1 et contiennent "test": true dans les données du payload.
Pushes signés sur les remises échangées via l'Open Order Handoff Protocol : changements de cycle de vie (acceptée, refusée, expirée, annulée), réponses aux avenants, événements de suivi et nouvelles lignes de règlement. Abonné par jeton OHP via POST /api/v1/ohp/subscriptions ; le point de terminaison doit renvoyer un défi avant que l'abonnement existe. Chaque charge est l'enveloppe OHP ; message_id reste identique à chaque nouvelle tentative — dédupliquez dessus. Le pull reste la source de vérité.
Signature et Vérification: X-Ohp-Signature : v1= + HMAC-SHA256 hexadécimal de "{timestamp}.{raw body}" avec le secret de l'abonnement. X-Ohp-Timestamp change à chaque tentative ; X-Ohp-Delivery égale message_id. CloudEvents et Standard Webhooks sont disponibles par abonnement.
Comment Configurer: Géré avec le jeton OHP : POST /api/v1/ohp/subscriptions (url, secret, events, format, signature), GET pour lister, DELETE pour révoquer. Le catalogue lisible par machine liste chaque événement sous l'expéditeur ohp.
Événements fins et optionnels à côté du webhook classique order.status_change (inchangé) : qui a été affecté, si le chauffeur a accepté, quand le colis a été récupéré, est en route, livré ou en échec, ainsi que les changements de service des chauffeurs et leurs positions à fréquence limitée. Rien n'est envoyé tant que vous n'avez pas configuré les URL ci-dessous.
Un chauffeur a été affecté à la commande (manuellement, par la planification des tournées ou par l'affectation automatique). data.source = auto_assign lorsque c'est l'orchestrateur qui l'a fait.
Exemples de Charge UtileLa commande a perdu son chauffeur (transfert, retrait, refus, délai dépassé). data.previous_driver_id indique qui l'avait.
Exemples de Charge UtileLe chauffeur a accepté dans l'app une commande affectée automatiquement (service des chauffeurs avec acceptation obligatoire).
Exemples de Charge UtileLe chauffeur a refusé une commande affectée ; data.reason contient le motif facultatif en texte libre.
Exemples de Charge UtileLe chauffeur a commencé le ramassage (statut Ramassage commencé / En cours de ramassage).
Exemples de Charge UtileLe colis a été récupéré (statut Déjà collecté).
Exemples de Charge UtileLe colis est en route vers le destinataire (statut Livraison commencée / En cours de livraison).
Exemples de Charge UtileLa livraison a réussi (statut Réussie).
Exemples de Charge UtileLa tentative de livraison a échoué (Relivrer plus tard, À replanifier, Refusé par le destinataire).
Exemples de Charge UtileLa commande a été annulée.
Exemples de Charge UtileLe personnel (ou un chauffeur, si autorisé) a marqué la commande comme prête pour le ramassage (Options de dispatch → prêt pour ramassage).
Exemples de Charge UtileUn chauffeur a pris ou quitté son service dans l'app (option service des chauffeurs).
Exemples de Charge UtileUne position du chauffeur provenant de l'app ou du traceur, limitée par chauffeur via driver_location_min_interval_sec (60 s par défaut). Envoyée uniquement à driver_location_webhook_url.
Exemples de Charge UtileComment Configurer: Paramètres → Webhooks (ou GET/PUT /api/v1/webhook-settings, GraphQL webhookSettingsUpdate) : order_lifecycle_webhook_url reçoit tous les événements order.* ainsi que driver.on_duty_changed ; order_lifecycle_events les restreint à une liste séparée par des virgules ; driver_location_webhook_url et driver_location_min_interval_sec contrôlent driver.location_update. Plusieurs URL peuvent être séparées par des virgules. Les envois apparaissent dans le journal de livraison des webhooks avec reference_type order / driver.
Signature et Vérification: Signé exactement comme tout autre webhook sortant de votre compte : en-tête Signature historique plus X-Webhook-Id / X-Webhook-Timestamp / X-Webhook-Signature-V2 avec votre webhook_sign_secret. Les nouvelles tentatives réutilisent le même event_id : dédupliquez sur cette valeur.
Événements facultatifs pour les colis traités par vos casiers intelligents, bornes et boîtes de dépôt intelligentes : un colis déposé dans une machine, retiré, sorti par le personnel ou ayant dépassé son délai de retrait, ainsi que les problèmes ouverts ou résolus à son sujet. Purement additif : aucun webhook existant ne change, et rien n'est envoyé tant que vous n'avez pas configuré device_order_webhook_url.
Un colis a été déposé dans la machine et attend la personne suivante (destinataire, coursier ou opérateur, voir data.device_order.next_actor). due_at est la date limite de retrait.
Exemples de Charge UtileLe colis a été retiré par la personne qu'il attendait : le destinataire, le coursier ou le personnel qui vide une boîte de dépôt intelligente.
Exemples de Charge UtileLe personnel a sorti le colis de la machine. removal_reason en indique la raison : overdue_return, handover, relay, anomaly ou recovery.
Exemples de Charge UtileLe colis a dépassé son due_at sans être retiré. Il est toujours dans la machine et son code fonctionne encore ; overdue_at est renseigné et next_actor devient operator.
Exemples de Charge UtileUn problème a été ouvert sur ce traitement (par exemple door_left_open, deposit_unverified, item_missing, overdue). data.exception contient id, type, severity et status.
Exemples de Charge UtileUne personne a clos un problème sur ce traitement. data.exception.status vaut resolved ou dismissed et resolution_action indique ce qui a été fait.
Exemples de Charge UtileExemples de Charge Utile: data.device_order : id, kind, status, next_actor, device_type, device_id, device_name, grid_code, reference_number, order_id, external_order_id, due_at, overdue_at, stored_at, ended_at, removal_reason (heures au format ISO 8601, null tant qu'elles ne sont pas atteintes). Les événements de problème ajoutent data.exception : id, type, severity, status, resolution_action. Le code de retrait n'est jamais inclus. event_id vaut DOE-<id de l'événement du registre> et reste identique lors des nouvelles tentatives.
Comment Configurer: Paramètres → Webhooks (ou GET/PUT /api/v1/webhook-settings) : device_order_webhook_url reçoit chaque événement device_order.* ; device_order_events le restreint à une liste séparée par des virgules. Plusieurs URL peuvent être séparées par des virgules. Les livraisons apparaissent dans le journal de livraison des webhooks avec reference_type device_order.
Signature et Vérification: Signé exactement comme tout autre webhook sortant de votre compte : en-tête Signature historique plus X-Webhook-Id / X-Webhook-Timestamp / X-Webhook-Signature-V2 avec votre webhook_sign_secret. Les nouvelles tentatives réutilisent le même event_id : dédupliquez sur cette valeur.
Les colis qu'un transporteur partenaire livre dans vos casiers sous son propre compte ne sont pas envoyés sur ce canal ; le partenaire les reçoit via ses webhooks de casiers fournisseur.
Vous pouvez configurer les webhooks à deux niveaux : au niveau de l'entreprise (couvre tout) ou par client (remplacement pour ce sous-compte B2B spécifique).
Connectez-vous et allez dans Paramètres → API & Webhooks. Les remplacements par client sont sur la page de détail du client.
Choisissez une chaîne d'au moins 16 caractères, idéalement 32+ octets aléatoires. Votre récepteur utilise ce secret pour vérifier les signatures.
Remplissez uniquement les URLs des événements qui vous intéressent. Laissez les autres vides.
webhook_sign_secretVous configurez un secret partagé sur la page de paramètres. Chaque webhook sortant est signé avec ce secret. Votre récepteur recalcule la signature et compare — si elles correspondent, la charge utile est authentique et non altérée.order_create_webhook_urlSe déclenche à la création d'une commande de livraison locale (Delivery / Pickup / P2P), quel que soit le canal : formulaire web, API REST/GraphQL, synchronisation plateforme e-commerce, règles automatiques, lignes d'import, etc. Exclut les commandes label-service et les autres types non-livraison. Ignoré dans le flux batch lorsque order_create_async_postback_url est également configuré pour le même destinataire. Configurez via order_create_webhook_url.order_status_change_webhook_urlSe déclenche à chaque transition de statut — récupéré, en transit, livré, exception, annulé. Configurez via order_status_change_webhook_url.tracking_event_webhook_urlSe déclenche à chaque événement du cycle de vie d'un colis (informations soumises, début de livraison, livraison réussie, non livré, etc.). Configurez via tracking_event_webhook_url. Les événements « livré » et « ramassé » transportent aussi la preuve de livraison : proof_files et proof_files_detail (file_id, type, url, full_url, URL de téléchargement signée). Les photos téléversées après l’événement arrivent via pod.files_updated. Chaque fichier porte aussi le contexte de son événement : tracking_event_id, tracking_event_status_id, tracking_event_key, service_type (1 = delivery / 2 = pickup) et service_status (1 = success / 2 = failed) ; ils valent null pour les anciens fichiers sans événement enregistré.order_create_async_postback_urlSe déclenche une fois après le traitement d'un import par lot. La charge contient le tableau des résultats par ligne. Configurez via order_create_async_postback_url.pod_files_webhook_urlDéclenché quand une photo de livraison ou une signature est ajoutée, remplacée ou supprimée (action : added / updated / removed) — un envoi par fichier, plus besoin d’interroger les pièces jointes. Activé via pod_files_webhook_url. Chaque fichier porte aussi le contexte de son événement : tracking_event_id, tracking_event_status_id, tracking_event_key, service_type (1 = delivery / 2 = pickup) et service_status (1 = success / 2 = failed) ; ils valent null pour les anciens fichiers sans événement enregistré. Lorsqu'un employé remplace une photo ou une signature, ou définit une version archivée comme actuelle, le fichier est envoyé avec action: updated et ne contient que l'image actuelle ; les versions archivées ne sont jamais envoyées.order_deleted_webhook_urlDéclenché quand une commande est supprimée définitivement, afin que votre système puisse refléter la suppression. Activé via order_deleted_webhook_url.order_cancel_failed_webhook_urlDéclenché quand une tentative d'annulation est refusée (par exemple la commande est déjà en cours de livraison), afin que vos équipes puissent surveiller les annulations échouées sans interroger l'API. Activé via order_cancel_failed_webhook_url.route_board_webhook_urlDéclenché lorsqu'un siège du tableau des tournées change de titulaire ou que le tableau change d'état — le champ action indique ce qui s'est passé (claimed, standby, pooled, promoted, withdrawn, vetoed, replaced, assigned, awarded, lost, displaced, settled, board_opened, board_closed, board_cancelled). Niveau entreprise uniquement. Abonnement via route_board_webhook_url.device_order_webhook_urlÉvénements facultatifs pour les colis traités par vos casiers intelligents, bornes et boîtes de dépôt intelligentes : un colis déposé dans une machine, retiré, sorti par le personnel ou ayant dépassé son délai de retrait, ainsi que les problèmes ouverts ou résolus à son sujet. Purement additif : aucun webhook existant ne change, et rien n'est envoyé tant que vous n'avez pas configuré device_order_webhook_url.Toutes les nouveautés de l’API et des webhooks — annulation idempotente, flux de réconciliation, signatures v2, nouveaux événements — avec des exemples prêts à copier. Le tout entièrement rétrocompatible.
Chaque webhook sortant porte une signature HMAC-SHA256 encodée en hexadécimal dans l'en-tête. Votre récepteur doit recalculer la signature sur le corps brut avec le secret partagé et rejeter la requête si elle ne correspond pas.
Chaque URL de webhook peut recevoir les événements au format natif ou en CloudEvents, et peut aussi recevoir les en-têtes de signature Standard Webhooks. Ce réglage se fait par URL dans les paramètres de webhook. Une URL sans réglage reçoit les événements exactement comme avant.
native — Le corps JSON et les en-têtes décrits sur cette page.ce_binary — Le même corps ; les attributs CloudEvents sont envoyés dans des en-têtes ce-*.ce_structured — Le corps est un CloudEvent (Content-Type: application/cloudevents+json) avec le corps natif dans data. Il est identique à chaque nouvelle tentative et les signatures natives le couvrent.ce-id et webhook-id portent l’event_id propre à l’événement lorsque le corps en a un, sinon X-Webhook-Event-Id. X-Webhook-Event-Id lui-même ne change pas. ce-source et ce-srbusiness désignent l’entreprise, y compris pour les envois à ses clients.
Les webhooks de livraisons en consignes partenaires et de livraison tierce offrent le même choix par endpoint, sur la page des paramètres de webhook du prestataire. Les rappels de plans de chargement et d’Open Platform le reçoivent par requête : callback_format et callback_signature, ou callback.format et callback.signature. Pour eux, ce-id et webhook-id sont l’identifiant propre de l’événement (X-Webhook-Id, X-Webhook-Event-Id ou X-Open-Delivery), ce-source désigne l’entreprise émettrice, et pendant 24 heures après une rotation de clé du prestataire webhook-signature porte une signature par clé.
Les webhooks de jeux de données offrent le même choix par webhook, dans le formulaire du webhook et dans son API (event_format et standard_signature). Standard Webhooks utilise la clé secrète du webhook et en exige donc une. Les URL des webhooks de jeux de données doivent être des adresses HTTPS publiques.
Avec Standard Webhooks, chaque envoi porte aussi webhook-id, webhook-timestamp et webhook-signature. Ils sont signés à nouveau à chaque nouvelle tentative, qui reste donc dans une tolérance de 5 minutes. La clé est votre clé de signature de webhook au format whsec_, affichée sur la page des paramètres. Les en-têtes natifs sont toujours envoyés.
Chaque expéditeur signe différemment. Le nom d’en-tête X-Webhook-Signature est utilisé par trois expéditeurs avec trois méthodes différentes ; vérifiez avec la méthode de l’expéditeur qui vous a appelé.
| Expéditeur | En-têtes | Signature |
|---|---|---|
| Webhooks locataire (cette page) | Content-Type, Signature, X-Webhook-Event-Id, X-Webhook-Timestamp, X-Webhook-Signature-V2 |
Signature = hex(HMAC-SHA256(body))
X-Webhook-Signature-V2 = hex(HMAC-SHA256(timestamp + "." + body)) |
| Livraisons en consignes partenaires | Content-Type, X-Webhook-Id, X-Webhook-Delivery-Id, X-Webhook-Timestamp, X-Webhook-Key-Id, X-Webhook-Content-Digest, X-Webhook-Signature, X-Webhook-Test |
X-Webhook-Signature = "v1=" + base64(HMAC-SHA256(timestamp + "\n" + delivery_id + "\n" + body)) |
| Affectations à une livraison tierce | Content-Type, X-Webhook-Id, X-Webhook-Delivery-Id, X-Webhook-Timestamp, X-Webhook-Key-Id, X-Webhook-Content-Digest, X-Webhook-Signature |
X-Webhook-Signature = "v1=" + base64(HMAC-SHA256(timestamp + "\n" + delivery_id + "\n" + body)) |
| Rappels de plans de chargement | Content-Type, X-Webhook-Event-Id, X-Webhook-Event-Type, X-Webhook-Timestamp, X-Webhook-Signature |
X-Webhook-Signature = "v1=" + hex(HMAC-SHA256(timestamp + "." + body)) |
| Rappels de tâches Open Platform | Content-Type, X-Open-Event, X-Open-Delivery, X-Open-Job, X-Open-Timestamp, X-Open-Signature |
X-Open-Signature = "v1=" + hex(HMAC-SHA256(timestamp + "." + body)) |
| OHP push | Content-Type, X-Ohp-Event, X-Ohp-Delivery, X-Ohp-Timestamp, X-Ohp-Signature |
|
| Webhooks de jeux de données | Content-Type, X-Webhook-Event, X-Webhook-Timestamp, X-Webhook-Signature |
X-Webhook-Signature = hex(HMAC-SHA256(body)) |
| Webhooks locataire avec Standard Webhooks | webhook-id, webhook-timestamp, webhook-signature |
webhook-signature = "v1," + base64(HMAC-SHA256(webhook-id + "." + webhook-timestamp + "." + body)) |
Votre prestataire peut masquer ses prix à un compte client, par famille de commande (Livraison Locale, Service d'étiquettes, Service d'expédition, Service LTL, Services de stockage, Services de déménagement, commandes d'appareil). Lorsque cela vous concerne, les livraisons vers votre point de terminaison ne contiennent aucun champ de prix : shipping_price, price_details, currency, taxes, montants de suppléments, prix des tarifs, etc. sont omis plutôt qu'envoyés à zéro. Les listes de tarifs conservent rate_id et les noms de service pour qu'un service puisse encore être choisi.
Votre endpoint devrait répondre rapidement avec 2xx. Sinon, ou en cas de timeout ou inaccessibilité, la livraison est retentée.
Collez une charge utile reçue, la valeur de l'en-tête Signature et votre secret — l'outil recalcule la signature dans votre navigateur (rien ne quitte cette page) et indique si elles correspondent.
Déclenchez un vrai webhook signé depuis notre serveur vers une URL que vous fournissez. Utile pour tester l'accessibilité du récepteur, l'analyse de la charge utile et la logique de vérification de signature.
Consultez les tentatives de livraison de webhook les plus récentes sur votre compte — événements de production et tests depuis cette page. Collez votre Bearer token pour charger.
Les enregistrements de livraison sont conservés 90 jours.
Un renvoi manuel reçoit un nouveau X-Webhook-Event-Id. Un event_id porté par l’événement lui-même (pod.files_updated, order.deleted, événements de cycle de vie et de commandes d’appareil) garde sa valeur d’origine.
| Heure | Événement | URL | Statut | HTTP | Tentative | Temps (ms) | Test ? | Actions |
|---|---|---|---|---|---|---|---|---|
| Aucune livraison de webhook trouvée pour l'instant. | ||||||||