Make · Hilfe

Make HTTP: Airtable-Webhook scheitert mit 422?

curl funktioniert, Make meldet Parameter validation failed? Vergleiche den wirklich gesendeten JSON-Body, Header und aufgelöste Werte.

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

Kurzantwort

HTTP 422 beim Anlegen eines Airtable-Webhooks in Make beweist weder eine allgemeine Make-Störung noch automatisch fehlende Berechtigung. Wenn der vergleichbare Aufruf anderswo funktioniert, prüfe zuerst den tatsächlich ausgewerteten Request: Endpunkt, Identität, JSON-Eingabeart, Datentypen und Content-Type. Gleich aussehender Editorinhalt kann anders übertragen werden. Für einen erneuten Erstelltest müssen außerdem bereits entstandene Webhooks berücksichtigt werden, weil der Aufruf echte Einträge erzeugt.

Quellengrundlage: Q1 · Q2 · Q3

Gilt für
Der Ausgangsbericht betrifft Airtable-Webhook-Erstellung über Make HTTP. Die geprüfte Dokumentation beschreibt HTTP-Modulversion 4; genaue Airtable-Feldanforderungen sind am jeweiligen aktuellen Endpunkt zu prüfen.
So prüfst du das Ergebnis
Der beabsichtigte Webhook wird eindeutig identifiziert, frühere Versuche sind abgeglichen, und eine harmlose Teständerung erreicht den richtigen Empfänger im vorgesehenen Ereignisumfang.
Deine erste Prüfung

Ist der tatsächlich gesendete Body strukturell identisch mit dem funktionierenden Request?

Ein Request zum Anlegen eines Airtable-Webhooks funktioniert außerhalb von Make, im HTTP-Modul kommt jedoch 422 mit einer Parameterprüfung zurück. Der sichtbare JSON-Text scheint identisch. Jetzt zählt der tatsächlich übertragene Request, einschließlich Datentypen und ausgewerteter Mappingwerte.

Gleich aussehender Text kann anders übertragen werden

Ein Originalbericht beschreibt genau diese Abweichung beim Erstellen eines Airtable-Webhooks. Er belegt keine bestätigte generelle Make-Störung. Q1 Die aktuelle Make-HTTP-Dokumentation unterscheidet einen JSON-String von einer strukturierten JSON-Eingabe und sieht eigene Felder für Authentifizierung und Inhaltstyp vor. Q2 Airtable empfiehlt für die Untersuchung den konkreten Request und Fehler, ausdrücklich ohne geheimen API-Key. Q3

Behandle die Meldung nicht automatisch als fehlende Berechtigung. Vergleiche zuerst, ob die beiden Tests wirklich denselben Endpunkt, dieselbe Identität und denselben Inhalt verwenden.

Den Unterschied isolieren

  1. Vergleich einfrieren. Notiere HTTP-Methode, API-Pfad, Base-Referenz, Modulversion und Zeitpunkt beider Versuche. Ein funktionierender alter Test mit anderen Werten ist kein passender Gegenbeleg.
  2. Aufgelöste Eingabe prüfen. Öffne im Make-Lauf die tatsächlichen Moduleingaben. Sind Werte leer geworden, Arrays zu Text geworden oder Objekte doppelt als JSON-String verpackt? Prüfe nicht nur den Editor vor Auswertung der Ausdrücke.
  3. Inhaltstyp und Header abgleichen. Vergleiche die ausgewählte JSON-Eingabeart mit dem erwarteten Body. Vermeide widersprüchliche doppelte Content-Type-Angaben. In HTTP-Version 4 sollten Geheimnisse über die vorgesehenen Credential-Felder verwaltet werden.
  4. Übertragung ohne Geheimnisse sichtbar machen. Falls nötig, verwende einen eigenen kontrollierten Testempfänger mit neutralem Body und unechten Zugangswerten. Sende keine Airtable-Tokens oder Kundendaten an öffentliche Request-Inspektoren.
  5. Minimalen gültigen Test vorbereiten. Vergleiche die benötigten Felder mit der aktuellen Airtable-Endpunktdokumentation für dein Vorhaben. Teste anschließend einmal in einer geeigneten Test-Base. Berücksichtige, dass ein erfolgreicher Erstellaufruf tatsächlich einen neuen Webhook anlegt.

Nach dem korrigierten Request

Prüfe, welcher Webhook angelegt wurde und ob mehrere frühere Versuche bereits Einträge erzeugt haben. Ordne Benachrichtigungsziel und beabsichtigten Ereignisumfang zu, bevor die Verbindung produktiv genutzt wird. Eine 2xx-Antwort ist nur der erste Nachweis; die gewünschte harmlose Teständerung muss am vorgesehenen Empfänger sichtbar werden.

Häufige Fragen

Soll ich den API-Token neu erzeugen?

Nicht allein wegen dieses Befunds. Wenn derselbe autorisierte Request andernorts funktioniert, ist der übertragene Inhalt ein besonders sinnvoller erster Vergleich.

Welche Unterlagen helfen bei der Diagnose?

Ein redigierter funktionierender Request, die tatsächlichen Make-Eingaben, Modulversion und vollständiger Fehlerbody. Erhalte Struktur und Datentypen, ersetze aber Tokens, echte Datensatzwerte und vertrauliche URLs.

Unterstützung für diesen Fall

Wir helfen dir, den betroffenen Ablauf einzugrenzen und die nächste Maßnahme kontrolliert vorzubereiten. Fall A0418 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.