Skip to main content
Cette page rassemble tout : un endpoint de réception de webhook prêt à l’emploi, de la vérification de signature jusqu’au rebuild. Le modèle est toujours le même.

Le modèle en 5 temps

1

Vérifier la signature

Recalculez le HMAC sur le corps brut et comparez-le à X-LeCommis-Signature à temps constant. Rejetez (401) sinon. Voir Sécurité.
2

Répondre 2xx immédiatement

Acquittez la livraison avant tout traitement long, pour rester sous les timeouts (lecture 5 s).
3

Dédupliquer puis enfiler un job async

Ignorez les delivery_id déjà vus, sinon poussez le traitement dans une file de tâches de fond. Voir Retries & idempotence.
4

Re-fetch l'API

Selon changed_resources (ou simplement si content_revision a augmenté), appelez les endpoints publics concernés.
5

Invalider le cache / rebuild

Purgez votre cache ou déclenchez un rebuild de votre site statique.

Endpoint complet

Node.js (Express)

Re-fetch et authentification

Les appels de re-fetch ciblent l’API et nécessitent l’en-tête X-Api-Key. La clé API et le secret de webhook sont deux secrets distincts : gardez-les tous deux côté serveur, jamais exposés au navigateur.

Checklist de mise en production

Le corps brut (raw body) est lu avant tout parsing JSON.
La signature est vérifiée à temps constant, et le timestamp rejeté au-delà de 5 min.
Une signature invalide renvoie 401 et n’entraîne aucun traitement.
L’endpoint répond 2xx avant de re-fetch ou rebuild ; le travail part en async.
Les livraisons sont dédupliquées sur X-LeCommis-Delivery.
L’URL de réception est en HTTPS public et répond sous quelques secondes.
Un type d’événement inconnu est ignoré proprement (pas d’erreur).

Pour aller plus loin

Sécurité & signature

Le détail de la vérification HMAC.

content_revision

Détecter les changements et invalider le cache.