Webhooks. Événements en temps réel, livrés de manière fiable.

Lisez le corps brut de la requête en octets (avant tout parsing JSON), calculez le HMAC-SHA256 sur les octets bruts avec le secret partagé de votre endpoint, encodez en base16 (hex) le résultat, et comparez-le à la valeur de l'en-tête X-Elido-Signature après avoir retiré le préfixe 'sha256='. Utilisez une fonction de comparaison à temps constant (par ex. hmac.compare_digest en Python, crypto.timingSafeEqual en Node.js) pour prévenir les attaques temporelles. Ne comparez jamais la signature avec un opérateur d'égalité de chaîne standard. Exemples de code pour Node.js, Python et Go à /docs/guides/webhooks#verification.

Renvoyez HTTP 200 (ou tout code de statut 2xx) dans les 30 secondes. Le corps de la réponse est ignoré - vous pouvez renvoyer un corps vide ou { ok: true }. Si votre traitement prend plus de 30 secondes, renvoyez 200 immédiatement et traitez l'événement de manière asynchrone (ajoutez à une file interne, renvoyez 200, traitez hors du chemin de la requête). Renvoyer 4xx est traité de la même façon que 5xx pour les nouvelles tentatives - les deux déclenchent un nouvel essai. Renvoyez 200 même si l'événement n'est pas pertinent pour votre intégration (par ex. un événement link.created dont vous n'avez pas besoin) pour éviter les nouvelles tentatives parasites.

Chaque payload webhook inclut un champ event_id (UUID). Utilisez-le comme clé d'idempotence sur votre récepteur : si vous recevez le même event_id deux fois (suite à une nouvelle tentative après un échec partiel), ne le traitez qu'une seule fois. Stockez les event_id reçus dans une table de déduplication avec un TTL d'au moins 72 heures (la fenêtre de nouvelles tentatives). Le payload de nouvelle tentative est identique à l'original - même event_id, même corps - donc une simple vérification « ai-je déjà vu cet event_id ? » suffit.

Les endpoints sont automatiquement mis en pause après 30 échecs de livraison consécutifs (non-2xx ou timeout). Cela empêche Elido de marteler un endpoint défaillant indéfiniment. Corrigez le problème sous-jacent (généralement : l'URL de l'endpoint a changé, le serveur est hors service, ou le timeout de 30 secondes est dépassé à cause d'un traitement lent), puis reprenez l'endpoint dans le dashboard. Une fois repris, Elido ne rejoue pas automatiquement les événements ignorés pendant la pause - rejouez-les manuellement depuis le journal de livraison si vous devez récupérer ces événements.

Oui - activez le mode raw-click sur l'endpoint. En mode raw-click, Elido délivre les événements click.created individuellement sans fenêtre d'agrégation, dans les 2 secondes du clic. Sachez qu'un workspace actif peut produire des milliers d'événements par minute en mode raw-click ; assurez-vous que votre récepteur peut gérer le débit. Pour la plupart des cas d'analyse, l'agrégation par lots par défaut de 5 secondes (jusqu'à 100 clics par payload) est suffisante et produit beaucoup moins de requêtes HTTP.

Les payloads d'événements individuels font moins de 10 Ko. Les payloads de clics par lots (mode par défaut) peuvent contenir jusqu'à 100 événements, avec une taille totale plafonnée à 100 Ko. Si un lot dépasse 100 Ko, il est automatiquement divisé en plusieurs livraisons. Les champs de métadonnées volumineux (par ex. de longues URL de referrer) sont tronqués à 2 Ko par champ. Si votre récepteur impose une limite stricte de taille de payload, configurez le mode raw-click (un événement par livraison) au lieu du mode par lots.

Utilisez un outil comme ngrok, Cloudflare Tunnel ou localtunnel pour exposer votre serveur local avec une URL HTTPS publique, puis enregistrez cette URL comme endpoint webhook dans votre workspace de test. Alternativement, utilisez le bouton de test webhook dans le dashboard pour envoyer un payload d'exemple pour tout type d'événement à un endpoint enregistré sans déclencher un événement réel. Le CLI Elido (elido webhook test --event click.created --endpoint https://...) fonctionne également pour les tests locaux scriptés.

Les événements générés pendant une fenêtre de maintenance sont mis en file d'attente dans notre flux d'événements et délivrés après la fin de la maintenance. La page de statut Elido (status.elido.app) annonce les fenêtres de maintenance planifiées à l'avance. Le SLA de livraison webhook exclut les fenêtres de maintenance annoncées. Pour une fenêtre de maintenance typique de 30 à 60 minutes, la fenêtre de nouvelles tentatives de 72 heures garantit qu'aucun événement n'est définitivement perdu - ils sont délivrés dans l'ordre de génération une fois l'endpoint à nouveau accessible.