🔗 Testeur de Webhooks IFTTT ☆

Testez les webhooks IFTTT sans quitter votre navigateur

Testeur de Webhooks IFTTT Gratuit envoie une requête POST directement à maker.ifttt.com avec le nom de l'événement, votre clé et jusqu'à trois valeurs JSON, exactement comme votre applet l'attend. Idéal pour déboguer, vérifier les clés et confirmer la réception du payload.

Comment tester un applet

• Créez un applet Webhooks sur IFTTT et copiez votre clé depuis la page du service
• Saisissez le nom de l'événement et votre clé ci-dessus
• Ajoutez value1, value3 si votre applet les utilise, puis envoyez

Bon à savoir

• La requête part directement de votre navigateur vers IFTTT, sans proxy
• Un test réussi signifie seulement que IFTTT a accepté le déclencheur ; vérifiez le journal de l'applet
• Votre clé n'est jamais stockée ni journalisée

Comment fonctionne le test de webhook

Les webhooks IFTTT sont de simples endpoints HTTPS : la clé est dans le chemin et un corps JSON optionnel transporte jusqu'à trois valeurs. Le testeur envoie une vraie requête depuis votre navigateur (soumise au CORS, la réponse peut être opaque) et rapporte le statut HTTP, le temps et la réponse lisible quand elle l'est. Un 200 confirme clé et nom d'événement ; 401 et 404 pointent une clé ou un événement erronés. Le test ne prouve pas que l'action de l'applet s'est exécutée.

Formats, limites et paramètres

Confidentialité : rien ne passe par 0Appz

Une clé IFTTT peut déclencher de vraies automatisations : l'envoyer à un testeur tiers est un vrai risque. Ici la requête part de votre navigateur vers IFTTT ; la clé est saisie dans la page, utilisée localement et jamais transmise ni stockée.

Liste de dépannage des webhooks

• Vérifiez que le nom d'événement correspond exactement, sensible à la casse.
• Recopiez la clé depuis la page Webhooks : les espaces la cassent.
• Contrôlez que l'applet est connecté et activé.
• CORS peut masquer la réponse même en cas de succès : utilisez le journal.
• Régénérez la clé si elle a été collée dans un outil non fiable.

Voir aussi les outils de développement pour en-têtes, webhooks et débogage d'API.

Webhooks, payloads et codes de réponse

Un webhook n'est qu'une requête HTTP qu'un service adresse à une URL que vous contrôlez, et le tester signifie reproduire fidèlement cette requête. La méthode est presque toujours POST et le corps est généralement du JSON, donc l'en-tête Content-Type doit indiquer application/json, sinon l'automatisation réceptrice peut rejeter le payload. Le service Webhooks d'IFTTT est un cas particulier : il accepte trois valeurs nommées value1, value2 et value3, envoyables en corps JSON ou en champs de formulaire encodés dans l'URL. Rester dans ces trois champs est la principale contrainte de conception : emballez donc des données structurées dans une seule chaîne JSON dans value1 si vous avez besoin de plus. Les codes de réponse disent ce qui s'est passé : 200 signifie que le service a accepté l'événement, 400 indique souvent un JSON mal formé ou un champ manquant, 401 ou 403 que la clé est erronée ou révoquée, et 404 que le nom d'événement n'existe pas. Un 500 est le problème du service, pas le vôtre, et réessayer la même requête est raisonnable. Deux remarques opérationnelles : beaucoup de services dédupliquent les payloads identiques, donc un test envoyant deux fois le même corps peut ne se déclencher qu'une fois, et les intermédiaires réseau peuvent mettre en cache ou bloquer des requêtes sans les bons en-têtes. Lors des tests, vérifiez aussi le corps de la réponse et pas seulement le code, car certaines API renvoient 200 avec un objet d'erreur à l'intérieur.