Webhook.site

Une URL unique en 2 secondes pour voir enfin ce que vos webhooks envoient réellement.

webhook.site Recopier avec ClaudeEnregistrer

Webhook.site génère instantanément une URL (et une adresse e-mail) unique et jetable sur laquelle n'importe quel service tiers (Stripe, GitHub, Shopify, un CRM, une app mobile...) peut envoyer des requêtes HTTP, des e-mails ou du DNS. Le développeur voit apparaître en temps réel le contenu brut de chaque requête (headers, body, query params) dans une interface web, sans écrire une ligne de code côté serveur. Au-delà de l'inspection, l'outil permet de transformer les requêtes, de les renvoyer (forward) vers une autre URL avec retries automatiques, de déclencher des actions personnalisées (scripts, envoi d'e-mail, écriture dans Google Sheets/Slack/S3), et de planifier des exécutions via cron. Le produit existe en version cloud (gratuite avec limites, payante en Basic/Pro/Enterprise) et en version open-source self-hostable (Docker, licence MIT), ce qui a largement contribué à sa notoriété auprès des développeurs.

Plus les ronds sont verts, plus le SaaS est intéressant à cloner.

La difficulté technique de cloner le cœur du produit (générer une URL unique, afficher les requêtes en temps réel) est modérée grâce aux frameworks modernes, mais la robustesse à grande échelle (réception d'e-mails via MX, DNS hooks, WebSockets fiables, rétention de données, domaines personnalisés) demande un vrai travail d'infrastructure, d'où un score de 5/10. La saturation est assez élevée (7/10) : Beeceptor, RequestBin, Hookdeck Console, Pipedream et Svix couvrent des angles proches (inspection, mocking, delivery outbound), rendant la différenciation pure sur l'inspection de webhooks plus difficile qu'en 2016. L'opportunité reste moyenne (5/10) : le marché existe et est prouvé rentable en solo, mais un nouvel entrant doit trouver un angle (verticalisation sur un écosystème précis, meilleure UX pour équipes, tarification plus agressive) plutôt que copier frontalement un acteur déjà installé et gratuit dans sa version de base.

Évolution du MRR

Suivi du MRR démarré le 16/07/2026 — la courbe se construit jour après jour, à mesure que nos agents re-vérifient les chiffres.

Comment ils ont grandi

Simon Fredsted crée Webhook.site en 2016 comme un outil personnel pour tester les webhooks d'une autre application qu'il développait, puis le rend public. Un post Hacker News lui apporte une première vague massive de trafic et installe le produit dans les habitudes des développeurs du monde entier. Pendant près de dix ans, le produit croît de façon quasi entièrement organique, sans budget marketing ni levée de fonds, porté par un nom de domaine générique très bien référencé et par le bouche-à-oreille technique. Le fondateur reste seul aux commandes, ajoutant progressivement des fonctionnalités premium (Custom Actions, domaines personnalisés, SSO, multi-utilisateurs) pour monétiser les équipes et entreprises, tout en gardant une version open-source gratuite qui entretient la confiance de la communauté. Aujourd'hui, Webhook.site tourne à environ 200 000 visites mensuelles et 20 000 $ de MRR, un cas d'école de micro-SaaS développeur rentable géré par une seule personne.

Ad Spy — voir les publicités

Un développeur cherche généralement à comprendre pourquoi un webhook Stripe, GitHub ou Shopify n'arrive pas comme prévu, et tape 'test webhook' ou 'webhook url generator' dans Google, ou tombe sur le nom de domaine générique webhook.site directement suggéré par un tutoriel ou un collègue. La landing page va droit au but : une URL unique est déjà générée et affichée en gros, sans aucune inscription requise, avec un panneau vide prêt à recevoir la première requête. L'utilisateur copie cette URL dans la configuration webhook du service tiers qu'il teste, envoie une requête de test, et voit apparaître en temps réel, grâce aux WebSockets, le détail complet de la requête (headers, body JSON, query params) dans l'interface. Cette gratification immédiate sans friction de compte est le moteur principal de conversion vers l'usage régulier. Après plusieurs sessions, l'utilisateur découvre les limites du mode anonyme (URL expirable, historique limité) et crée un compte gratuit pour obtenir une URL permanente et un historique plus long. En explorant les fonctionnalités, il rencontre les Custom Actions et le Forwarding, qui nécessitent un abonnement payant pour un usage intensif ou en équipe. Le déclencheur de paiement est souvent professionnel : une équipe veut partager un espace de debug commun, dépasser le quota de requêtes gratuites, brancher un domaine personnalisé, ou activer le SSO pour des raisons de sécurité interne. L'utilisateur atterrit alors sur la page de tarification, compare Basic, Pro et Enterprise selon le nombre d'URLs et l'historique nécessaire, et paie via Paddle en carte bancaire, mensuellement ou annuellement avec la remise de 20 %. La récurrence de l'usage (chaque nouveau projet ou intégration API nécessite un test de webhook) crée une fidélisation naturelle sans effort marketing additionnel, et la version open-source sur GitHub rassure les équipes techniques sur la pérennité et la transparence de l'outil avant l'achat.