Airtable Webhooks Ignore URL Query Parameters. Here Is the Fix.

If you have tried to build a clickable link that triggers an Airtable automation, you have probably hit this wall: the record ID sits right there in the URL, but your "Update record" step has nothing to read. The data is in the link and the automation cannot see it.

This comes up whenever someone wants a one-click link. A link goes out in an email or a chat message, and opening it should update a record, say, mark it as done. The link is built with a formula that drops the record ID into the URL, something like ?recordId=rec123. It looks correct. It does not work.

Why it fails

Airtable's "When webhook received" trigger has two hard rules:

1. It only accepts a POST request.
2. It only reads data from the JSON body of that request.

A clicked link is neither of those things. When a person clicks a URL, the browser sends a GET request, and a GET carries its data in the query string, not in a body. So your record ID travels in the URL, arrives at a trigger that only reads the body, and the body is empty. Airtable parses nothing from the query string. Your automation fires with no data to map.

This is not a configuration you are missing. Airtable's webhook trigger has no option to read query parameters, and there is a long-standing open request asking for one. Today the answer is simply that the trigger reads the body and only the body.

The workarounds people reach for

The usual advice is to stop using a plain link and send a real POST instead:

• A script or another tool (Make, Zapier, a small server) sits in the middle, receives the click, and re-sends the data to Airtable as a POST with a JSON body.
• Double-encoding tricks where the whole payload is stuffed into one field and parsed back out on the Airtable side.

These work, but they all mean standing up and maintaining something extra just to turn one click into one record update.

A second, quieter problem

Even if you get a GET link working through some workaround, there is a trap waiting. Link-scanners in email and messaging tools routinely open URLs on their own to generate previews and run security checks. A webhook link that fires the moment it is opened gets triggered by those scanners before any person opens it, and records start updating themselves. The link really needs to fire only when a real person opens it, not on an automated preview.

The fix: a free relay

We built a small free tool that handles both problems: the Airtable webhook relay.

Instead of pointing your link straight at Airtable, you point it at the relay. When someone opens it, the relay POSTs the values from the URL to your webhook as a proper JSON body. Airtable receives a real body and your "Update record" step reads the record ID from it. The relay forwards from the page once it loads in a real browser rather than on the bare request, so link-scanners that preview the URL without running scripts will not fire it by accident.

You paste in your webhook URL, with whatever query parameters you already put on it, and it gives you a relay link to drop into an email or a message. The relay lifts those parameters off the URL and sends them to Airtable as the body. There is nothing to host and nothing to maintain. The relay only ever forwards to hooks.airtable.com, and it does not store your webhook URL or your data.

To send a different record per row, wrap your existing webhook field (the one that already builds the URL with the record ID) in a formula field:

"https://www.collabportals.com/tools/airtable-webhook-relay/send?hook=" & ENCODE_URL_COMPONENT({Webhook URL})

When you want more than a link

A relay is the right tool when you genuinely just need a one-click action. But if the reason you are building these links is that people outside Airtable need to see and act on your data without a seat, a link per record gets fiddly fast. That is the problem CollabPortals is built for: connect an Airtable base, publish a branded portal, and let clients or teammates log in to view and update only the records meant for them, with no Airtable seat required. If that sounds closer to what you are actually after, the use cases are a good place to start.