Make Webhook erstellen: Schritt-für-Schritt für Anfänger 2026
Diese Anleitung zeigt dir, wie du in Make einen Custom Webhook erstellst, testest und als sofortigen Trigger für dein Szenario verwendest.
Einen Make Webhook erstellen klingt technischer, als es ist. Ein Webhook ist im Grunde eine URL, an die eine andere App Daten sendet. Sobald Make diese Daten empfängt, kann dein Szenario direkt starten – ohne regelmäßig nach neuen Daten suchen zu müssen.
Das Ergebnis: Du erstellst in Make einen Custom Webhook, kopierst die erzeugte URL, sendest Testdaten und verwendest die erkannten Felder anschließend in weiteren Modulen.
Affiliate-Hinweis: Dieser Beitrag enthält einen Partnerlink zu Make. Wenn du dich darüber registrierst oder später einen Tarif buchst, kann Miligenza eine Provision erhalten. Für dich wird es dadurch nicht teurer.
Inhaltsverzeichnis
Was ist ein Webhook in Make?
Ein Webhook ist eine HTTPS-Adresse, die Daten von außen empfangen kann. Statt dass Make alle paar Minuten bei einer App nachfragt, sendet die externe Anwendung die Daten direkt an Make.
Beispiel: Ein Chatbot sammelt Name und E-Mail-Adresse. Sobald der Nutzer das Formular abschickt, sendet der Bot die Daten an die Make-Webhook-URL. Make startet sofort und verarbeitet den Datensatz weiter.
Make unterscheidet zwischen app-spezifischen Instant-Triggern und Custom Webhooks. Für einen frei nutzbaren Endpunkt verwendest du die Webhooks-App.
Schritt 1: Custom Webhook erstellen
Erstelle ein neues Szenario und füge als erstes Modul Webhooks hinzu. Wähle anschließend Custom webhook.
Klicke im Feld Webhook auf Add und vergib einen eindeutigen Namen, beispielsweise „Kontaktformular Website“.
Schritt 2: Webhook-URL kopieren
Nach dem Anlegen erzeugt Make eine individuelle URL. Kopiere sie in die Zwischenablage. Diese Adresse wird später in der App hinterlegt, die Daten an Make senden soll.
Behandle die Webhook-URL wie einen technischen Zugangspunkt. Veröffentliche sie nicht unnötig und teile sie nur dort, wo sie tatsächlich benötigt wird.
Instant oder geplant: Wie soll dein Webhook laufen?
Ein Custom Webhook arbeitet normalerweise als Instant-Trigger. Sobald eine Anfrage eingeht, startet Make den Ablauf direkt. Du kannst die Verarbeitung aber auch planen. Dann sammelt Make die eingehenden Requests zunächst in der eigenen Webhook-Queue und verarbeitet sie nach dem eingestellten Zeitplan.
| Variante | Typischer Einsatz |
|---|---|
| Instant | Formulare, Chatbots, Bestellungen oder andere Ereignisse, auf die sofort reagiert werden soll |
| Geplant | Daten bewusst bündeln, Lastspitzen kontrollieren oder Requests nur zu bestimmten Zeiten verarbeiten |
Für den ersten Test ist Instant meistens einfacher, weil du unmittelbar siehst, ob der Request angekommen ist.
Schritt 3: Testdaten an den Webhook senden
Make muss einmal sehen, wie deine Daten aufgebaut sind. Starte deshalb die Erkennung beziehungsweise Run once und sende anschließend einen Testrequest an die Webhook-URL.
Für einen einfachen Test kann der Absender beispielsweise JSON senden:
{"name":"Test","email":"test@example.com"}
Wenn Make die Daten erfolgreich empfängt, zeigt das Modul einen erkannten Datensatz an. Ab diesem Moment stehen die Felder im Mapping der nachfolgenden Module zur Verfügung.
Testrequest direkt aus Make senden
Du brauchst dafür keinen externen Onlinedienst. Lege ein zweites, vorübergehendes Szenario mit HTTP → Make a request an. Es dient nur als Absender; das Webhook-Szenario bleibt der Empfänger.
| Feld im HTTP-Modul (Version 4) | Wert für diesen Test |
|---|---|
| Authentication type | No authentication – nur wenn du am Webhook keine zusätzliche Authentifizierung eingerichtet hast |
| URL | Deine vollständige, zuvor kopierte Webhook-URL |
| Method | POST |
| Body content type | application/JSON |
| Body input method | JSON string |
| JSON-Inhalt | {"name":"Test","email":"test@example.com"} |
| Parse response | No, wenn die Standardantwort einfacher Text ist |
- Speichere das HTTP-Modul. Öffne den Empfänger in einem zweiten Browser-Tab und starte dort Run once beziehungsweise die Datenstrukturerkennung.
- Starte unmittelbar danach im Absender-Szenario Run once.
- Prüfe am Empfänger, ob ein Bundle mit
name = Testundemail = test@example.comangekommen ist.
Ein HTTP-Erfolgsstatus allein beweist noch nicht, dass alle nachfolgenden Module erfolgreich waren. Kontrolliere zusätzlich die Ausführung im Empfänger. Beide Testläufe können Credits verbrauchen. Lass den Absender ohne aktiven Zeitplan.
Feldreferenz: offizielle HTTP-Moduldokumentation.
Warum die Datenstruktur beim ersten Test wichtig ist
Make lernt die Struktur deines Webhooks aus den empfangenen Testdaten. Wenn du beim Test nur name und email sendest, später aber zusätzlich telefon, produkt oder verschachtelte Objekte brauchst, können diese Felder im Mapping zunächst fehlen.
Sende deshalb beim ersten Test möglichst ein realistisches Datenpaket mit allen Feldern, die dein späterer Workflow benötigt. Ändert sich die Struktur später grundlegend, solltest du die Datenstruktur neu bestimmen und anschließend jedes Mapping kontrollieren.
Schritt 4: Webhook-Daten weiterverwenden
Füge rechts neben dem Webhook ein zweites Modul hinzu. Du kannst die Daten beispielsweise in Google Sheets speichern, per Gmail verschicken oder an WordPress weitergeben.
Beim Mapping wählst du die Felder aus, die der Webhook im Test erkannt hat.
Der Webhook liefert die Daten. Das nächste Modul entscheidet, was damit passiert.
Optional: Eine eigene Webhook-Antwort senden
Mit dem Modul Webhook Response kannst du dem aufrufenden Dienst eine eigene HTTP-Antwort zurückgeben. Das ist beispielsweise sinnvoll, wenn dein Formular oder deine Anwendung wissen soll, ob Make die Anfrage erfolgreich verarbeitet hat.
Ohne eigenes Response-Modul verwendet Make Standardantworten. Für viele einfache Einweg-Integrationen reicht das völlig aus.
Platziere ein Webhook-Response-Modul möglichst am Ende des Szenarios. Make weist darauf hin, dass Fehler in späteren Modulen sonst nicht mehr sauber über die ursprüngliche Webhook-Antwort sichtbar werden und dadurch unbemerkte Fehler entstehen können.
Schritt 5: Szenario aktivieren
Webhooks können als Instant-Trigger arbeiten. Standardmäßig startet Make das Szenario, sobald eine Anfrage eingeht. Du kannst Webhook-Szenarien aber auch so planen, dass Anfragen zunächst in der Queue gesammelt und später verarbeitet werden.
Aktiviere dein Szenario erst, wenn ein vollständiger Testrequest erfolgreich bis zum letzten Modul gelaufen ist.
Webhook-Queue, parallele Verarbeitung und Reihenfolge
Bei Instant-Webhooks verarbeitet Make eingehende Requests standardmäßig parallel. Wenn die Reihenfolge wichtig ist, kannst du in den Szenario-Einstellungen Process data in order aktivieren. Dann wartet Make auf das Ende der vorherigen Ausführung.
Bei höherem Volumen solltest du außerdem Queue, Rate Limits und Fehlerbehandlung beobachten. Make dokumentiert aktuell bis zu 300 eingehende Webhook-Requests innerhalb von zehn Sekunden; bei Überschreitung kann ein HTTP-429-Fehler entstehen.
Jeder Webhook besitzt eine eigene Queue. Bei geplanten Webhooks landen eingehende Requests dort, bis der Zeitplan sie verarbeitet. Die mögliche Queue-Größe hängt von deinem Credit-Kontingent ab. Make nennt aktuell 667 Queue-Einträge pro 10.000 lizenzierte Credits, maximal 10.000 pro Webhook.
Webhook sicher produktiv einsetzen
- Veröffentliche die vollständige Webhook-URL nicht in Screenshots, Foren oder öffentlichen Dokumenten.
- Teste mit realistischen, aber nicht sensiblen Beispieldaten.
- Prüfe bei produktiven Workflows regelmäßig Logs und Queue.
- Setze Szenario-Rate-Limits, wenn der sendende Dienst in kurzen Lastspitzen sehr viele Requests erzeugt.
- Aktiviere Process data in order nur dann, wenn die Reihenfolge wirklich relevant ist, weil dadurch parallele Verarbeitung bewusst ausgeschaltet wird.
Behandle einen Webhook nicht wie eine beliebige öffentliche URL. Wer den Endpunkt kennt, kann Requests an ihn senden. Nutze deshalb zusätzliche Prüfungen im Workflow, wenn dein Absender Signaturen, Tokens oder andere verifizierbare Merkmale mitsendet.
Fazit: Webhooks sind der direkte Eingang in dein Make-Szenario
Ein Custom Webhook eignet sich immer dann, wenn ein externer Dienst Daten direkt an Make senden kann. Du sparst regelmäßige Polling-Abfragen und reagierst meist sofort auf neue Ereignisse.
Wenn du Webhooks bereits in Verbindung mit einem Chatbot einsetzen willst, findest du auf Miligenza die Anleitung Botpress mit Make.com verbinden.
Du möchtest Make selbst ausprobieren?
Starte mit dem kostenlosen Tarif und teste den beschriebenen Ablauf zuerst mit Testdaten.
Partnerlink: Miligenza kann bei einer Registrierung oder einem späteren Kauf eine Provision erhalten. Für dich bleibt der Preis gleich.
Häufige Fragen zu Make Webhooks
Was ist ein Custom Webhook in Make?
Ein Custom Webhook ist eine von Make erzeugte HTTPS-URL, an die externe Apps oder Dienste Daten senden können.
Startet ein Webhook sofort?
Instant-Webhooks können das Szenario direkt nach Eingang der Anfrage starten. Alternativ lässt sich die Verarbeitung planen und über die Queue sammeln.
Kann Make JSON per Webhook empfangen?
Ja. JSON ist ein typisches Format für Webhook-Requests. Make analysiert die empfangenen Daten und stellt die erkannten Felder für das Mapping bereit.
Werden Webhooks parallel verarbeitet?
Bei Instant-Webhooks standardmäßig ja. Wenn Reihenfolge wichtig ist, kannst du in den Szenario-Einstellungen „Process data in order“ aktivieren.
Kann ich eine eigene Antwort an den Absender zurückgeben?
Ja. Dafür gibt es das Modul Webhook Response, mit dem Status, Header und Body der Antwort angepasst werden können.
Wie teste ich einen neuen Make Webhook?
Starte „Run once“, sende genau einen Testdatensatz an die Webhook-URL und kontrolliere anschließend, ob Make die erwarteten Felder erkannt hat.
Quellen und Transparenz: Die Webhook-Schritte wurden anhand der aktuellen Make-Webhooks-Dokumentation geprüft. Stand: 4. Oktober 2026. Make kann Funktionen, Preise, Modulnamen und Limits jederzeit ändern. Miligenza ist nicht Make.com und erklärt die Plattform unabhängig.
Offizielle Quellen: Webhooks · Szenario-Einstellungen · Szenario planen & Rate Limits