Make · Help

Make HTTP: creating an Airtable webhook fails with 422?

curl works but Make returns a parameter-validation error? Compare the transmitted JSON body, headers and resolved values.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

HTTP 422 when creating an Airtable webhook in Make proves neither a general Make defect nor automatically missing permission. If a comparable request works elsewhere, inspect the evaluated endpoint, identity, JSON input mode, data types and Content-Type first. Similar editor text can be transmitted differently. Before repeating creation, also identify webhooks already produced by earlier attempts because the request creates real entries.

Source basis: Q1 · Q2 · Q3

Applies to
The reported case concerns Airtable webhook creation through Make HTTP. Reviewed documentation covers HTTP module version 4; verify exact Airtable field requirements for the current endpoint.
How to verify the result
The intended webhook is identified, earlier attempts are reconciled, and one harmless test change reaches the correct receiver with the intended event scope.
Your first check

Is the transmitted body structurally identical to the working request?

A request to create an Airtable webhook works outside Make, but the HTTP module returns 422 with a parameter-validation error. The visible JSON looks identical. Investigate the request actually transmitted, including data types and evaluated mapping values.

Similar-looking text can be transmitted differently

An original report describes this discrepancy when creating an Airtable webhook. It does not establish a confirmed general Make defect. Q1 Current Make HTTP documentation distinguishes a JSON string from structured JSON input and provides dedicated authentication and content-type fields. Q2 Airtable asks for the concrete request and error during investigation, explicitly excluding the secret API key. Q3

Do not automatically interpret the message as missing permissions. First compare whether both tests really use the same endpoint, identity and content.

Isolate the difference

  1. Freeze the comparison. Record method, API path, base reference, module version and timestamps for both attempts. An older successful request with different values is not a suitable control.
  2. Inspect evaluated input. Open the actual module inputs from the Make execution. Have values become empty, arrays become text, or objects been encoded twice as JSON strings? Inspect the evaluated request rather than only the editor before expressions resolve.
  3. Compare content type and headers. Match the selected JSON input method to the intended body. Avoid conflicting duplicate Content-Type declarations. In HTTP version 4, manage secrets through the dedicated credential fields.
  4. Observe transport without secrets. If needed, use your own controlled test receiver with neutral content and dummy credentials. Do not send Airtable tokens or customer data to public request-inspection services.
  5. Prepare a minimal valid test. Compare required fields against the current Airtable endpoint documentation for the intended operation. Then perform one controlled test in an appropriate test base. Remember that a successful creation call creates a real webhook.

After correcting the request

Identify the webhook created and check whether earlier attempts already produced additional entries. Confirm its notification destination and intended event scope before production use. A 2xx response is the first check; an intended harmless test change must also reach the correct receiver.

Keep the redacted before-and-after requests so a difference in body encoding or resolved values remains visible. That is more useful than a screenshot showing only the final success status.

Frequently asked questions

Should I generate another API token?

Not solely because of this symptom. If the same authorised request works elsewhere, the transmitted content is a particularly useful first comparison.

What information helps diagnose it?

Provide a redacted working request, actual Make inputs, module version and complete error body. Preserve structure and types while replacing tokens, real record values and confidential URLs.

Help with this case

We can help isolate the affected process and prepare a controlled next step. Discuss case A0418 with KAN KAI WORKS.

Support with this issue

We investigate Make using your error message, versions and a narrowly scoped example.

Describe your case →Related service: AI & automation

Sources

Sources checked on 5 November 2026. Individual reports do not establish general prevalence.