En-têtes de la requête
Chaque livraison porte ces en-têtes :Les événements de test envoyés depuis le tableau de bord portent
x-pulse-id et x-pulse-event mais pas x-pulse-delivery-id, car aucun enregistrement de livraison n’est créé pour eux. Leur charge utile contient également un champ note supplémentaire. Les événements réels portent toujours les quatre en-têtes.Le secret de signature
Chaque Pulse possède son propre secret de signature, préfixéwhsec_, généré par Chariow à la création du Pulse.
Pour le récupérer : Automatisations → Pulses → sélectionnez votre Pulse → onglet Aperçu → Secret de signature. Il est masqué par défaut ; utilisez Révéler, Copier et Renouveler sur ce bloc.
Le secret est chiffré au repos et n’apparaît jamais dans les listings d’API ni dans les journaux de requêtes — ceux-ci n’exposent qu’une forme masquée du type whsec_••••a1b2. La valeur en clair n’est renvoyée que sur une demande de révélation explicite.
Renouveler le secret
Le renouvellement prend effet immédiatement et est irréversible : l’ancien secret cesse de fonctionner à l’instant du renouvellement. Mettez à jour la configuration de votre point de terminaison dans la même fenêtre. Les livraisons émises avant le renouvellement conservent la signature calculée avec l’ancien secret : adoptez le nouveau secret avant de rejouer d’anciennes livraisons.Schéma de signature
x-pulse-id, x-pulse-delivery-id et tout horodatage sont exclus du calcul.
Encodage du corps
Le corps est du JSON compact en UTF-8 :- aucun espace d’indentation ni retour à la ligne ;
- les barres obliques sont échappées —
https:\/\/example.com; - les caractères non-ASCII sont échappés en
\uXXXX, le corps transmis est donc en pratique de l’ASCII ; - l’ordre des clés est celui du corps transmis.
Comparer la signature
Retirez le préfixesha256= et comparez à l’empreinte hexadécimale seule, ou reconstruisez "sha256=" + empreinte et comparez la chaîne complète. Les deux fonctionnent, à condition d’être cohérent.
Comparez toujours en temps constant (crypto.timingSafeEqual, hash_equals, hmac.compare_digest) et vérifiez d’abord que les deux valeurs ont la même longueur — timingSafeEqual lève une exception sur des tampons de tailles différentes.
Le préfixe identifie l’algorithme afin que le schéma puisse évoluer sans casser les intégrations existantes. Traitez toute valeur qui ne commence pas par sha256= comme un schéma que vous ne prenez pas encore en charge.
Exemples de vérification
Idempotence et protection contre le rejeu
La signature ne contient aucun horodatage, et c’est délibéré. Elle est calculée une seule fois à l’émission de la livraison et réutilisée à l’identique par chaque réessai. Une fenêtre temporelle rejetterait à tort un réessai légitimement retardé — la dernière tentative d’une livraison peut arriver près de trois heures après la première. La protection contre le rejeu repose surx-pulse-delivery-id. Cet identifiant est stable sur toutes les tentatives d’une même livraison, ce qui en fait une clé d’idempotence directement exploitable :
- Lisez
x-pulse-delivery-id. - Si vous l’avez déjà traité, renvoyez
200et arrêtez-vous. - Sinon, persistez-le, renvoyez
200, puis traitez de façon asynchrone.
x-pulse-delivery-id : elle passera donc votre contrôle d’idempotence et sera traitée à nouveau. C’est le comportement voulu — le rejeu existe précisément pour retraiter un événement que votre point de terminaison a manqué.
Diagnostiquer une signature qui ne correspond pas
Ressources associées
Guide des Pulses
Événements, charges utiles, historique de livraison et réessais
Meilleures pratiques
Recommandations de sécurité et de fiabilité