🔗 IFTTT-Webhook-Tester ☆

IFTTT-Webhooks testen, ohne den Browser zu verlassen

Kostenloser IFTTT-Webhook-Tester sendet eine POST-Anfrage direkt an maker.ifttt.com, mit Event-Namen, Key und bis zu drei JSON-Werten, genau wie Ihr Applet es erwartet. Ideal zum Debuggen, Key-Prüfen und Bestätigen, dass der Dienst das Payload erhält.

So testen Sie ein Applet

• Webhooks-Applet auf IFTTT erstellen und den Key von der Dienstseite kopieren
• Event-Namen und Key oben eingeben
• Value1, Value3 ergänzen, falls das Applet sie nutzt, und senden

Gut zu wissen

• Die Anfrage geht direkt vom Browser an IFTTT, ohne Proxy
• Ein erfolgreicher Test heißt nur, dass IFTTT den Trigger akzeptiert hat; prüfen Sie das Applet-Protokoll
• Ihr Key wird nie gespeichert oder protokolliert

So funktioniert der Webhook-Test

IFTTT-Webhooks sind einfache HTTPS-Endpunkte: Der Key steht im Pfad, ein optionaler JSON-Body trägt bis zu drei Werte. Der Tester sendet eine echte Anfrage aus dem Browser (CORS-bedingt kann die Antwort opak sein) und meldet HTTP-Status, Dauer und lesbare Antwort, wenn erlaubt. Ein 200 bestätigt Key und Eventnamen; 401 und 404 deuten auf falschen Key oder Event. Der Test beweist nicht, dass die Applet-Aktion lief, dafür das Aktivitätsprotokoll prüfen.

Formate, Grenzen und Parameter

Datenschutz: nichts läuft über 0Appz

Ein IFTTT-Key kann echte Automatisierungen auslösen, ihn in einen Fremd-Tester zu geben ist riskant. Hier geht die Anfrage direkt vom Browser an IFTTT: Der Key wird in die Seite eingegeben, lokal genutzt und nie an uns übertragen oder gespeichert.

Webhook-Debugging-Checkliste

• Eventnamen exakt prüfen, Groß-/Kleinschreibung zählt.
• Key von der Webhooks-Seite neu kopieren; Leerzeichen brechen ihn.
• Prüfen, ob das Applet verbunden und aktiv ist.
• CORS kann Antworten verbergen. Das Aktivitätsprotokoll nutzen.
• Key rotieren, falls er je in ein unsicheres Tool kopiert wurde.

Mehr: Entwicklerwerkzeuge für Header, Webhooks und API-Debugging.

Webhooks, Payloads und Antwortcodes

Ein Webhook ist nur eine HTTP-Anfrage, die ein Dienst an eine URL Ihrer Wahl sendet, und ihn zu testen heißt, diese Anfrage originalgetreu nachzubauen. Die Methode ist fast immer POST und der Body meist JSON, also muss der Content-Type-Header application/json sagen, sonst kann die empfangende Automatisierung die Payload ablehnen. Der Webhooks-Dienst von IFTTT ist ein Sonderfall: Er akzeptiert drei Werte namens value1, value2 und value3, die als JSON-Body oder als URL-kodierte Formularfelder gesendet werden können. In diesen drei Feldern zu bleiben ist die zentrale Design-Einschränkung, packen Sie strukturierte Daten in einen einzelnen JSON-String in value1, wenn Sie mehr brauchen. Antwortcodes sagen, was passiert ist: 200 bedeutet, der Dienst hat das Ereignis angenommen; 400 meist fehlerhaftes JSON oder ein fehlendes Feld; 401 oder 403, dass der Schlüssel falsch oder widerrufen ist; 404, dass der Ereignisname nicht existiert. Ein 500 ist das Problem des Dienstes, nicht Ihres, und ein erneuter Versuch ist sinnvoll. Zwei Betriebshinweise: Viele Dienste deduplizieren identische Payloads, ein Test mit demselben Body kann also nur einmal auslösen, und Netzwerk-Zwischenstellen können Anfragen ohne die richtigen Header cachen oder blockieren. Prüfen Sie beim Testen auch den Antwort-Body und nicht nur den Statuscode, denn manche APIs liefern 200 mit einem Fehlerobjekt darin.