Incoming webhooks for automations ✨

[Jason]

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 →

[Databaser]

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.

:man_shrugging:

[CVRR_Rescue]

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

[Bill_French]

Databaser:

ActiveCampaign sends webhooks only as application/x-www-form-urlencoded

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.

[ScottWorld]

Databaser:

The issue is caused because ActiveCampaign sends webhooks only as application/x-www-form-urlencoded, while Airtable requires them to be in JSON.

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:

ScottWorld:

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.

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.)

[Olpy_Acaflo]

Bill.French:

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

ScottWorld:

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.

ScottWorld:

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.

Hi @Jason ,

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

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.

[Bill_French]

Jason:

the other type of limitation is that there’s a payload size limit of 100kb per request.

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.

[kuovonne]

Bill.French:

a single event can only create (or update) a single record.

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.

Bill.French:

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.

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?

[Bill_French]

kuovonne:

Couldn’t those ten records all be stored in a single JSON property?

Precisely what I expected. Show me.

[kuovonne]

Bill.French:

Precisely what I expected.

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

Bill.French:

Show me.

[Bill_French]

kuovonne:

You expected that you would be able to store all the records in JSON?

Um, not exactly. I expected to be able to receive a post payload containing an array of JSON objects that I could parse and update into Airtable however desired. Perhaps a collection of new records, or perhaps a collection of updates to existing records - it doesn’t matter as long as the aggregate payload is available from the inputConfig() method.

My point is - given the JSON data is captured from a webhook, how would an array of objects be utilized in the script of the webhook action. It’s not clear to me from your example that you demonstrated this.

For example - given this payload:

… and thereafter configuring the script itself (to process this webhook post), it is apparently not possible to select the node “records”. You cannot select the entire payload being posted such that the script can then takeover and do as it must with the collection. What am I missing?