Incoming webhooks for automations ✨

On top of other releases this week, we have another exciting new feature - incoming webhooks for automations!

With the new incoming webhook trigger you can connect Airtable with many of the tools and products that you and your team use (whether a third-party service or an internal tool).

Normally, you’d have to write custom code and spin up your own infrastructure in order to handle webhooks, but now, whenever an event fires in another product, you can tap into the full power of Airtable Automations to handle it accordingly.

How it works

The incoming webhook trigger will create a unique URL that you can use to trigger an Airtable automation. You can use this URL with another service’s webhook configuration UI, or use it directly from your own custom code (e.g. from an internal tool). When Airtable receives a request at this URL, we’ll then trigger the automation that you configured (just like our other triggers).

This enables you to integrate with services that Airtable doesn’t currently support, or to programmatically trigger automations, preventing you from having to write custom code or manage your own infrastructure.

You can learn more about using the incoming webhook trigger in our Support Center.

View support article →


Nice! This is pretty awesome! This is a really big deal. :smiley: :raised_hands:

One feature request for webhooks:

In addition to sending JSON payloads to the webhook, it would be very cool if we also had the alternative option to send data to the webhook via simple URL parameters.

Thanks for creating this! :partying_face:


This is HUGE! I can’t wait to test it! (Just got the internet hooked up at our new house, but my desk didn’t survive the move, so I’m still on my phone…)


Perfect! Yet another step that erodes the grip that glue-factories have on Airtable systems. This was requested in 2016 by a number of users and I predicted this was inevitable as early as 2018. Outbound webhooks are surely imminent as well. The day has finally come and we can look forward to many new streamlined and performant interchanges from outside services.

Or, can we? :wink:

This will only serve to blind-side many unsuspecting users until Airtable addresses the capacity for pervasive, reliable, and sustained use of actions without arbitrary ceilings at a predictable cost that is conducive to the general market segment. Imagine if Tesla added a self-driving feature that abruptly terminated whenever it could not see roadside guardrails.

Are webhooks subject to quotas and if so, what [exactly] are the limitations?

If the limitations are strict and unforgiving (as they are now), we can expect slow adoption and a continued pummeling of Airtable servers with unending polling and continued decline in overall performance.


It is really hard to understate how huge this new feature is.

Such a small addition that will make such a gigantic impact. This is really a game changer for Airtable.

This one feature alone eliminates many of the reasons that we turn to Integromat.

However, you are very right when you say this:

This is such a great point for us to remember.

Growing businesses with thousands of records that depend heavily on automations can’t reliably use Airtable’s automations at this point, because if you go over your monthly quota of automation runs, Airtable completely disables all of your automations until your next billing cycle — with no way to pay for more automation runs in your current billing cycle.

An entire organization is effectively shut down until the next billing cycle.

It’s totally fine to disable automations when a customer has hit their monthly limit — this is obvious and expected — but customers need the ability to pay for more automation runs in the current billing cycle so their entire operations don’t grind to a halt until the next month.

I know that it seems like 50,000 runs in a month is a lot, but I have several large clients who are regularly running way more automation runs than that in a month with Integromat.

Of course, Airtable’s infrastructure might not be able to handle more than that, in which case it makes sense for Airtable to push those customers onto external automation platforms.

Outside of this one issue, I’m super excited about webhooks in Airtable! :star_struck::star2:

This is going to open up a whole new world of possibilities for people! :partying_face::tada:


Each webhook received that results in an automation run will count towards the automation run limits for your workspace plan. I’m checking in with our eng team to see what other quotas or limitations may exist.

1 Like

Hmm, doesn’t seem to work with ActiveCampaign… :unamused:

Jason, do you know if there are any plans to allow customers to pay for additional runs in a month, if they exceed their quota?

This is really the only issue at the moment for customers who need more than 50,000 runs in a month.

Besides this one issue, the automations platform is getting better & better every day! :slight_smile:


Are you posting your data to Aritable as a valid JSON payload with the Content-Type header of “application/json” and using the POST command?

If none of that is available to you, then it’s possible that ActiveCampaign might only support the URL-encoded way of sending data to webhooks, which I believe they call “form encoded payloads”. But that method is not currently supported by Airtable.

Hmm, not sure. It’s not mentioned on their help article. I’ll ask support.

For a quick update, the other type of limitation is that there’s a payload size limit of 100kb per request. Hope everyone has a good weekend.

Their reply:

The issue is caused because ActiveCampaign sends webhooks only as application/x-www-form-urlencoded, while Airtable requires them to be in JSON. The format would need to be converted somehow, unless Airtable has a workaround for accepting data in the x-www-form-urlencoded format.


That would be awesome. It would eliminate needing a script that users on the app cant use.

Shame on both vendors - ActiveCampaign for not supporting HTTPs JSON POST and Airtable for not supporting urlencoded forms.

This is what happens when two vendors decide to bake their cakes half way - a mushy, doughy, inedible blob of desert.


Ahhh, that’s a shame! Yeah, that’s what I thought the problem might be.

This same issue was my very first feature request to Airtable above about this new webhook integration:

In the meantime, until Airtable adds this feature into their webhooks, I would highly recommend checking out Integromat, which is my favorite professional webhook & professional automation platform.

I spend a lot of my professional Airtable consulting time working with Integromat, and it’s a great platform. Integromat accepts all forms of webhooks, and it also doesn’t have any automation run limits like Airtable does (i.e. you can pay for more runs if you hit the limit). They also offer full 100% Airtable support, and you can even create automations that communicate between different Airtable bases.

(Note that I am a professional Airtable consultant and a Registered Integromat Partner, and the Integromat link contains my personal referral code.)


Hi @Jason ,

Although I still couldn’t finance an indexed search system, I found this in my Assets :wink:

It seems to me that, whatever the costs / qualities / benefits generated by the cloudApp that I show as an example, as it would be out of thread’s scope, it would be very convenient to add this kind of plan to each Airtable’s paid Plan to buy automation credit whenever necessary without excluding the possibility to pay some more expensive Airtable Plan more adapted to its expected Automation consumption if it is required by the one who pays.

I don’t see this as a severe constraint given that a single event can only create (or update) a single record.

No credentials required?

But I’m curious about another seemingly missing constraint - security. It appears that posts into endpoints are secure only to the extent that the endpoint itself is obfuscated. Is that a correct assumption?

No ability to pass JSON payload to a script action in webhook?

Lastly, I see another constraint that is disconcerting. Imagine you had a webhook event from another database and it contained a payload consisting of ten records to add to an Airtable table. There is no apparent way to create a webhook that passes the payload into a follow-on script action - you can only pass properties of a JSON document.

Why is this concerning? Because it requires developers to handle webhooks one record/event per action. If I’m right about this inability to hand off a JSON payload to the script action when a webhook endpoint is called, it makes it impossible to optimize updates into Airtable. Ergo, it erodes the ability to control how we employ actions that themselves are constrained.

The only workaround for this is to create a proxy table that creates new records containing the entire payload and then use yet an additional action to parse the data from a long text field and apply such data as needed to multiple records.

If I’m wrong about this constraint, please advise.

1 Like

A scripting action can create/update/delete hundreds of records. Plus, each automation can have multiple actions. Even without scripting, an automation triggered by a webhook could theoretically alter up to 25 records.

Couldn’t those ten records all be stored in a single JSON property? I get that you cannot pass data that cannot be stored as JSON, but isn’t JSON sufficient for all of the values that could go directly into a field value? The script would have to be setup to parse the JSON properties, and creating the JSON on whatever platform calls the webhook might be a pain, but as long as it is consistent with the test, why wouldn’t it work?

Precisely what I expected. Show me.

You expected that you would be able to store all the records in JSON?
Or you expected someone to answer this way?

1 Like