Make · Hilfe

Make Custom Webhook antwortet „Unauthorized“?

Webhook-URL im Browser liefert Unauthorized? Prüfe API-Key-Header, IP-Regeln und den tatsächlich verwendeten Hook ohne Schutz abzuschalten.

Quellenstand: 5. November 2026Redaktion: KAN KAI WORKSRedaktionell aktualisiert:

Kurzantwort

Unauthorized beim direkten Öffnen eines Make-Webhooks kann eine korrekt arbeitende Zugriffskontrolle anzeigen. Ist API-Key-Authentifizierung eingerichtet, erwartet Make den Schlüssel im Header x-make-apikey; die Browseradresszeile sendet ihn nicht automatisch mit. Vergleiche zuerst die verwendete Hook-URL und ihre Schutzregeln mit der Anfrage des tatsächlichen Absenders. Prüfe anschließend einen harmlosen autorisierten Request und eine unberechtigte Gegenprobe, während der konfigurierte Schutz aktiv bleibt.

Quellengrundlage: Q1 · Q2

Gilt für
Gilt für Make Custom Webhooks mit optionaler API-Key-Authentifizierung und gegebenenfalls IP-Beschränkungen. Welche Regeln greifen, muss am tatsächlich verwendeten Hook geprüft werden.
So prüfst du das Ergebnis
Der vorgesehene autorisierte Test wird angenommen und verarbeitet den erwarteten Datensatz; eine Anfrage ohne Berechtigung bleibt abgewiesen, bei unverändert aktivem Schutz.
Deine erste Prüfung

Sendet der echte Absender den für diesen Hook eingerichteten API-Key-Header?

Du hast in Make einen Custom Webhook angelegt, kopierst seine URL in den Browser und erhältst „Unauthorized“. Das kann bereits eine korrekt arbeitende Zugriffskontrolle sein. Entscheidend ist, ob der echte Absender die für genau diesen Hook eingerichteten Zugangsinformationen mitsendet.

Browseraufruf und autorisierte Anfrage unterscheiden

Ein Originalbericht beschreibt dieses Verhalten beim direkten Öffnen der URL. Q1 Make dokumentiert optionale API-Key-Authentifizierung für Custom Webhooks: Der Schlüssel wird im Header x-make-apikey übermittelt. Daneben können IP-Beschränkungen gelten. Q2 Ein Aufruf über die Adresszeile enthält einen solchen selbst konfigurierten Header normalerweise nicht.

Das Fehlerbild ist daher kein hinreichender Grund, den Hook neu anzulegen oder seine Authentifizierung zu entfernen. Prüfe zunächst URL, Schutzkonfiguration und die tatsächliche Anfrage des vorgesehenen Absenders.

Den Zugriff sauber prüfen

  1. Richtigen Hook identifizieren. Vergleiche Organisation, Team, Szenario und die aktuell ausgewählte Webhook-Verbindung. Eine alte kopierte URL kann auf einen anderen Hook zeigen.
  2. Aktive Schutzregeln lesen. Prüfe, ob API-Key-Authentifizierung und IP-Regeln eingerichtet sind. Dokumentiere nur das Vorhandensein und die zuständige Identität; schreibe den Schlüssel nicht in eine öffentliche Fehlerbeschreibung.
  3. Absenderkonfiguration ansehen. Unterstützt der echte Dienst benutzerdefinierte Header? Wird x-make-apikey tatsächlich gesendet und stammt der Wert aus dem dafür vorgesehenen sicheren Speicher? Ein Schlüssel in der URL oder im JSON-Body ersetzt diesen Header nicht.
  4. Harmlosen Request isoliert testen. Verwende einen dafür vorgesehenen Testablauf ohne nachgelagerte externe Schreibaktionen. Vergleiche mit derselben URL eine korrekt autorisierte Anfrage und eine Anfrage ohne Berechtigung. Erwartet ist ein bewusst unterschiedliches Ergebnis.
  5. Bei weiterem Fehler Quelle prüfen. Vergleiche erlaubte IP-Bereiche mit der tatsächlichen Absenderinfrastruktur. Ein erfolgreicher Test vom Laptop kann eine andere Quelladresse verwenden als der spätere Dienst.

Nach erfolgreicher Annahme

Prüfe separat, ob die Nutzdaten dem erwarteten Aufbau entsprechen und das Szenario den gewünschten Testdatensatz verarbeitet. Eine angenommene HTTP-Anfrage beweist nicht automatisch den Erfolg aller nachfolgenden Module. Halte die Zuständigkeit für Schlüsselrotation fest; eine Änderung kann mehrere sendende Systeme betreffen.

Häufige Fragen

Soll ich den API-Key entfernen, damit der Browser funktioniert?

Nein. Teste die konfigurierte Authentifizierung mit einem geeigneten Client. Der Schutz muss nicht für einen unvollständigen Browseraufruf geschwächt werden.

Warum erscheint der Schlüssel nicht in den empfangenen Daten?

Make behandelt diesen reservierten Header besonders und bereinigt seinen Wert in der angezeigten Nutzlast. Q2 Nutze den Annahmestatus und eine kontrollierte Gegenprobe als Diagnose, statt das Geheimnis in andere Felder zu kopieren.

Unterstützung für diesen Fall

Wir helfen dir, den betroffenen Ablauf einzugrenzen und die nächste Maßnahme kontrolliert vorzubereiten. Fall A0336 mit KAN KAI WORKS besprechen.

Unterstützung bei diesem Fehler

Wir prüfen Make anhand deiner Fehlermeldung, Versionen und eines abgegrenzten Beispiels.

Fall beschreiben →Passende Leistung: KI & Automatisierung

Quellen

Quellen geprüft am 5. November 2026. Einzelfallberichte belegen keine allgemeine Verbreitung.