Svix
Service de webhooks open source — envoyez des événements à vos clients avec reprises, signature et historique de livraison
Svix est un service open source et auto-hébergeable pour envoyer des webhooks à vos propres clients : vous faites un appel d'API, et il prend en charge la livraison, les reprises, la signature du payload et l'historique par endpoint. Sous licence MIT, écrit en Rust, il comptait 3 376 étoiles GitHub en août 2026. Pour une petite équipe, cela transforme le "il faudrait supporter les webhooks" de quinze jours de plomberie de files en un après-midi — et cela compte plus qu'il n'y paraît, car les webhooks sortants sont la surface d'intégration la moins chère que vous puissiez offrir, et les intégrations sont de la distribution.
Ce qu'est Svix
Svix (github.com/svix/svix-webhooks) est le dispatcher open source derrière le service hébergé Svix. Votre application fait un seul appel d'API pour envoyer un message aux endpoints d'une application ; tout ce qui suit appartient à Svix. Il démarre depuis le fichier Docker Compose du dépôt, qui lance aussi les deux dépendances nécessaires : PostgreSQL pour le stockage et Redis — optionnel, version 6.2.0 ou supérieure — pour la file de tâches et le cache. Les bibliothèques officielles couvrent Go, Python, TypeScript, Java, Kotlin, Ruby, C#, Rust et PHP, avec en plus un provider Terraform et une CLI exécutable directement depuis npm.
- Des payloads signés. Des clés symétriques pré-partagées par défaut ; le README situe la signature symétrique à environ 50 fois plus rapide à signer et 160 fois plus rapide à vérifier que l'option asymétrique ed25519, également prise en charge lorsque vous préférez distribuer une clé publique plutôt qu'un secret.
- Des reprises et une file de messages morts. Des erreurs internes répétées finissent par placer une tâche dans une DLQ, et le README recommande d'en surveiller la profondeur via une métrique dédiée et de la rejouer depuis un endpoint d'administration une fois la cause corrigée.
- Une protection contre le SSRF. Les envois vers des adresses IP internes sont bloqués par défaut, avec une liste de sous-réseaux autorisés pour le cas où le destinataire est vraiment interne.
- Des webhooks opérationnels. Le serveur peut vous envoyer des webhooks à son propre sujet, ce qui vous apprend qu'un client a désactivé ou modifié un endpoint sans avoir à interroger quoi que ce soit.
Le README est inhabituellement franc sur ses propres limites : le service hébergé possède des fonctionnalités, des optimisations et des comportements qui ne sont pas encore dans le dépôt, et les deux sont décrits comme largement mais pas entièrement compatibles. Cela vaut la peine d'être lu avant de supposer une parité avec la version open source.
Pourquoi les webhooks sont une surface de croissance, pas seulement de la plomberie
Les webhooks sont classés comme sujet d'ingénierie, et c'est pour cela qu'ils sont toujours pour le trimestre prochain. Ce classement est une erreur. Un webhook sortant est la seule intégration que vous construisez une fois et jamais deux : une fois qu'elle existe, vos clients vous branchent eux-mêmes à Zapier, à n8n, à leurs scripts internes et à tout ce qu'ils utilisent déjà, et chacun de ces branchements est un partenariat que vous n'avez pas eu à négocier. Notre page sur l'intérêt de construire des intégrations développe l'argument complet ; les webhooks en sont la ligne la moins chère.
- De la distribution sans partenariat Un seul endpoint vous place à l'intérieur de tous les outils d'automatisation que vos clients paient déjà, sans livrer un connecteur pour aucun d'eux.
- De la rétention que vous n'avez pas eu à plaider Un client dont le système interne réagit à vos événements a un coût de changement qu'aucun tableau comparatif ne crée.
- Une surface de support moins chère "Pourquoi ça ne s'est pas déclenché" se répond depuis un journal de livraison que le client peut consulter, et non depuis vos propres logs à 23 h.
- Une raison d'écrire une documentation vraiment lue Les payloads d'événements font partie des rares pages de doc que l'on met en favori, ce qui en fait de très bonnes candidates au référencement.
Ce que le côté récepteur nous a appris
Nous n'envoyons pas de webhooks à grande échelle ; nous en consommons beaucoup, pour les paiements, pour la messagerie et pour chaque intégration que touchent nos agents. Deux habitudes en sont sorties, et toutes deux sont des décisions que l'on prend aussi côté émetteur. D'abord : un récepteur doit répondre 200 et enregistrer l'événement même quand la fonctionnalité qui le consomme est désactivée, car toute autre réponse fait réessayer l'émetteur, et une tempête de reprises est pire qu'un événement que l'on ignore. Ensuite : chaque handler doit pouvoir tourner deux fois sans dommage, parce que le même événement arrivera deux fois. Ce n'est pas un défaut de l'émetteur, c'est précisément ce que veut dire une livraison au moins une fois.
L'image miroir côté émetteur est ce que nous avons raté ailleurs et que nous ne répéterions pas : un succès de transport n'est pas un succès d'action. Nous avons un jour enregistré un post comme publié parce que l'appel HTTP renvoyait 200, alors que le corps en dessous disait qu'il avait été rejeté. Si c'est vous qui envoyez les webhooks, faites en sorte que l'enregistrement de livraison reflète ce qu'a dit le corps du récepteur et non la ligne de statut — et donnez à vos clients l'historique pour qu'ils puissent vous vérifier. Livrer des webhooks n'amène personne en soi ; les annoncer aux clients qui les demandaient, documenter les payloads et être listé là où cherchent les utilisateurs d'automatisation, voilà ce qui amène du monde. Cette moitié-là est le même travail de croissance que tout le reste, et c'est à cela que sert AgentCeres — the AI Growth Officer, sur agentceres.com : les agents rédigent l'annonce, la page de documentation et la prise de contact, et une personne valide ce qui part.
FAQ
- Auto-héberger Svix est-il gratuit ?
- Oui. Le dépôt est sous licence MIT et le serveur démarre depuis son propre Docker Compose avec PostgreSQL, plus Redis si vous voulez la file et le cache adossés à Redis. La même société vend une version hébergée, et le README dit explicitement que le dispatcher open source n'a pas toutes les fonctionnalités et optimisations du service hébergé. Mieux vaut confronter cela à vos besoins plutôt que de supposer qu'il s'agit du même produit.
- Ai-je vraiment besoin de Redis ?
- Pas forcément : le README indique PostgreSQL comme requis et Redis comme optionnel, pour la file de tâches et le cache. Si vous l'utilisez, deux notes de configuration du README sont faciles à manquer et coûteuses à apprendre : activez la persistance pour que les tâches en file survivent à un redémarrage, et réglez la politique d'éviction pour que les clés sans expiration explicite ne soient jamais évincées.
- Signatures symétriques ou asymétriques ?
- La symétrique est le défaut et la recommandation. Elle est nettement plus rapide des deux côtés et bien plus simple à vérifier pour vos clients, au prix d'un secret partagé par endpoint. La signature asymétrique ed25519 existe pour le cas où vous préférez publier une clé publique plutôt que distribuer des secrets, ce qui compte surtout quand vos récepteurs sont des tiers avec lesquels vous n'avez pas de relation de support.
- Ne vaudrait-il pas mieux construire l'envoi de webhooks moi-même ?
- C'est possible, et la première version est petite. Ce qui grossit, c'est tout ce qu'il y a autour : backoff exponentiel, désactivation d'un endpoint après des échecs répétés, protection contre le rejeu, rotation des secrets, un historique de livraison que vos clients peuvent lire, et une file qui ne perd pas d'événements au redémarrage du processus. C'est la même forme de faire-ou-acheter dont nous parlons dans dois-je créer mon propre agent marketing IA : le prototype tient en un week-end, la moitié opérationnelle non.
You built it. Now grow it.
AgentCeres is a managed AI marketing team — specialists draft the SEO, social, and outreach that fill your links, you approve what ships. 14-day free trial, from $39/month.