Passer au contenu principal
Les webhooks sortants permettent à vos systèmes de réagir aux événements de Flowella sans interroger l’API. Chaque webhook a une URL, un secret de signature et une liste de types d’événements. Lorsque l’un de ces événements se produit, Flowella envoie un POST JSON signé à l’URL. Vous pouvez gérer les webhooks dans l’application sous Settings → Webhooks (consultez Ajouter et gérer des webhooks sortants) ou avec l’API des webhooks. Cette page est la référence de ce que Flowella envoie.

Types d’événements

Cochez ces événements lorsque vous ajoutez un webhook, ou transmettez-les dans events lorsque vous en créez un avec l’API. Les événements de contact ne se déclenchent que pour ces appels API portant sur un seul contact. Ils ne se déclenchent pas pour POST /v1/contacts/bulk-upsert, pour les contacts créés par des messages entrants, ni pour les modifications effectuées dans l’application ou synchronisées depuis HubSpot.
Problème connu : optout.created ne se déclenche pas pour la première désinscription d’un contact sur un numéro WhatsApp, que le contact envoie un mot-clé ou que vous appeliez POST /v1/opt-outs. Pour l’instant, il ne se déclenche que lorsqu’un contact qui s’était réinscrit se désinscrit à nouveau. Ne comptez pas sur lui pour capturer toutes les désinscriptions : listez les désinscriptions avec GET /v1/opt-outs (scope contacts:read).
Flowella envoie aussi webhook.test lorsque vous sélectionnez Send test event dans l’application ou appelez POST /v1/webhooks/{id}/test. Vous ne pouvez pas vous y abonner. Son data vaut { "test": true, "sentAt": "<ISO 8601 time>" }.
Un même message sortant peut produire deux événements message.sent : l’un lorsque Flowella le transmet à Meta, l’autre lorsque Meta le signale comme envoyé. Les deux ont des valeurs id de premier niveau différentes. Utilisez data.messageId pour les rattacher au même message.

Format des requêtes

Flowella envoie chaque événement sous forme de POST HTTP avec ces en-têtes : Flowella n’envoie aucun autre en-tête personnalisé. Le type et l’identifiant de l’événement figurent dans le corps.

Corps

Chaque webhook a une version de payload, renvoyée sous payloadVersion par l’API des webhooks. La version 1 est la valeur par défaut pour chaque webhook, et aucun paramètre dans l’application ou l’API ne permet de la modifier. Les deux versions utilisent ces enveloppes :
Flowella n’envoie pas d’événement dont le data dépasse 256 Ko.

Vérifier les signatures

Vérifiez la signature de chaque requête avant de lui faire confiance. Flowella calcule X-Flowella-Signature ainsi :
  • Algorithme : HMAC avec SHA-256.
  • Clé : le secret de signature en texte UTF-8, exactement tel qu’il a été enregistré. Un secret généré par l’API inclut son préfixe whsec_.
  • Message : le corps brut de la requête, octet pour octet, tel que Flowella l’a envoyé. Rien d’autre n’est signé : la signature ne contient ni horodatage ni URL.
  • Sortie : hexadécimal minuscule, 64 caractères, sans préfixe sha256=.
Pour vérifier, calculez le même HMAC sur le corps brut et comparez-le à l’en-tête en temps constant. Pendant les 24 heures qui suivent un renouvellement via l’API, la requête porte les deux en-têtes : acceptez-la si l’un des deux correspond à un secret que vous détenez.
Calculez la signature sur le corps brut avant qu’un middleware ne l’analyse ou ne le reformate. Si votre framework analyse le JSON et que vous le sérialisez à nouveau, les octets changent et la signature ne correspond plus.

Réponses, relances et délais d’expiration

Flowella livre plusieurs événements simultanément, ils peuvent donc arriver dans le désordre. Utilisez created_at ou occurred_at si l’ordre compte. Répondez avec un statut 2xx dès que la signature est validée, puis traitez l’événement en arrière-plan. Pour l’affichage des relances dans l’application, consultez Relances et temporisation.

Dédupliquer les événements

Votre endpoint peut recevoir le même événement plusieurs fois : une relance alors que votre endpoint avait dépassé le délai mais traité la requête, ou un rejeu via l’API. Dédupliquez sur l’id de premier niveau :
  1. Enregistrez l’id de chaque événement que vous traitez.
  2. Si un id entrant est déjà enregistré, répondez 200 et ne faites rien d’autre.
  3. Conservez les identifiants enregistrés au moins aussi longtemps que vous êtes susceptible de rejouer des livraisons.
Ne dédupliquez pas sur data.messageId. Différents événements portant sur le même message, comme message.sent et message.delivered, le partagent.

Flux d’événements

Le flux d’événements est une alternative aux webhooks fondée sur l’interrogation. GET /v1/events renvoie les événements des 7 derniers jours, y compris ceux auxquels aucun webhook n’est abonné. Il nécessite le scope events:read. Filtrez avec type (un type ou une liste séparée par des virgules), occurredAfter et occurredBefore, et paginez avec limit et cursor. Chaque élément comporte id, type, occurredAt, version, correlationId et data. L’id correspond à l’id du corps du webhook, vous pouvez donc utiliser le flux pour combler les lacunes après une indisponibilité de votre endpoint.

Gérer les webhooks avec l’API

Tous les endpoints de webhooks nécessitent une clé API ou un jeton d’accès OAuth disposant du scope webhooks:manage. Les clés créées dans l’application en disposent. Consultez l’introduction à l’API pour l’authentification. Les objets webhook contiennent id, name, url, events, isActive, consecutiveFailures, signingSecretPrefix (les 8 premiers caractères du secret actuel), payloadVersion, lastTriggeredAt, disabledAt, createdAt et updatedAt. Quelques règles s’appliquent aux webhooks gérés via l’API :
  • Vous ne pouvez pas choisir le secret de signature via l’API. POST /v1/webhooks en génère un qui commence par whsec_ et le renvoie une seule fois, sous signingSecret.
  • Les rejeux ne sont pas pris en compte dans le compteur d’échecs et ne le réinitialisent pas. Flowella ne livre un rejeu que tant que le webhook est actif et toujours abonné à ce type d’événement.
  • L’URL doit respecter les mêmes règles d’URL que dans l’application.

Renouveler un secret de signature

Renouvelez un secret lorsque vous pensez qu’il a fuité, ou selon un calendrier régulier. Le renouvellement fonctionne pour tout webhook qui a un secret, y compris les webhooks dont vous avez saisi le secret dans l’application.
1

Demandez un nouveau secret

Appelez l’endpoint de renouvellement et enregistrez le signingSecret de la réponse. Flowella ne le renvoie qu’une seule fois.
2

Acceptez les deux secrets pendant 24 heures

Les nouvelles livraisons sont signées avec le nouveau secret dans X-Flowella-Signature, et avec l’ancien dans X-Flowella-Signature-Previous. Un gestionnaire qui utilise encore l’ancien secret continue de fonctionner s’il vérifie les deux en-têtes, comme dans l’exemple de Vérifier les signatures.
3

Passez au nouveau secret

Mettez à jour votre gestionnaire avec le nouveau secret dans les 24 heures. Passé ce délai, Flowella cesse d’envoyer X-Flowella-Signature-Previous.
Modifier le secret dans l’application avec New signing secret ne prévoit aucune période de chevauchement : l’ancien secret cesse immédiatement de fonctionner.

Tester en local

Pour recevoir des webhooks sur votre propre ordinateur, exposez votre serveur local via un tunnel public, comme ngrok ou Cloudflare Tunnel. Utilisez l’URL publique du tunnel comme endpoint. Utilisez ensuite Send test event pour envoyer des requêtes chaque fois que nécessaire. Flowella refuse les adresses locales et privées, une URL localhost ne fonctionne donc pas.

Voir aussi

Gérer les webhooks dans l'application

Ajoutez des endpoints, envoyez des événements de test et consultez le journal des livraisons.

Introduction à l'API

Authentification, scopes, limites de débit et erreurs.

Clés API

Créez la clé nécessaire pour l’API des webhooks.

Developer hub

Requêtes API récentes, guides de démarrage rapide et API sandbox.
Dernière modification le 24 octobre 2026