Incoming webhooks for automations ✨

Nice! This is pretty awesome! This is a really big deal. :grinning_face_with_big_eyes: :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? :winking_face:

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.

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! :slightly_smiling_face:

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.

:man_shrugging:

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

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.

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?

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?

I guess you have to trust me that I sent the JSON data using a webhook trigger.

• The overall layout of the screen should tell you that it is an automation script.
• The left section shows that I have only a single input variable for the automation.
• The middle section shows that I am taking that input variable and parsing the JSON.
• The right section shows both the original input variable’s value (as a JSON string), and the array that was created from parsing the JSON.

What you do with the array of objects, once it is an array of objects, is up to the script writer.
If you want to create new records, map it to the proper write format.

I’m passing a JSON string as the input variable in the webhook. I’m not passing an object; I’m passing a text string.
This may be where your habit of referring to JavaScript objects as JSON objects is mentally tripping you up.

Try this:

var recordData = [
  {
    "name": "Jubilee Organina", 
    "master__product__name": "Citris 250mg", 
    "source": "unifyd proxy"
  },
  {
    "name": "Jubilee Grape", 
    "master__product__name": "Citris 20mg", 
    "source": "unifyd proxy"
  },
]

var payload = {
  records: JSON.stringify(recordData),
}

So, it is not ideal, and it doesn’t match how other systems work. But I think that it will let you accomplish your end goal.

var recordData = [
  {
    "name": "Jubilee Organina", 
    "master__product__name": "Citris 250mg", 
    "source": "unifyd proxy"
  },
  {
    "name": "Jubilee Grape", 
    "master__product__name": "Citris 20mg", 
    "source": "unifyd proxy"
  },
]

var payload = {
  records: JSON.stringify(recordData),
}

@kuovonne,

Okay, I’m old and always making mistakes. In this case, I mistook making it clear that in many cases, we don’t have the ability to control the format of webhooks called by other platforms. Vastly, most data-centric platforms allow you to send webhooks based on events and such hooks include payloads that are often tightly aligned with the platform schema. Few allow users the latitude to alter the payload schemas, and when they do, it’s almost always a selection of fields, not the structure of the collection itself.

Lacking such ability to change the way any given platform broadcasts webhook objects or strings, Airtable must be able to tolerate arbitrary payload formats; this is precisely what I was expecting until my original post where I discovered this limitation.

In this example, I used one that looks like this which is a very common JSON format for conveying collections of anything.

Collections like this are commonplace in the world of webhook payloads and in many cases, they are more complex and more deeply nested. But if you try to use a script action to do something with this very common JSON payload, it appears to be impossible in Airtable.

As such, my original post stands unaddressed because I don’t think there is an answer; it’s simply a constraint that – in my view – is unnecessarily created by the Airtable UI - where the script action asks to identify the “properties” to retrieve as parameters from the webhook call. As you know, “properties” are limited to name → value pairs. But what they really should be asking in this context is what node or path should be passed into the script action and optionally what properties.

Ergo, it should be possible to select “body” or any other node on the JSON document’s path.

Ah. Thank you for explaining this. That makes a difference. I did point out initially that creating the JSON on whatever platform calls the webhook might be a pain.

Since you don’t have control over the payload, that makes things harder. If your objects are shallow and always have the same properties (like in your screen capture), you would have to resort to having input variables for each property and then manually reassembling the objects based on index. Not ideal, and it will still break if any property isn’t included, which you may also not have control over.

And all unnecessary if Airtable would simply follow a few open web standards like semantic XPath (circa 1999).

How did they not see this as a fundamental business requirement?

Yeah, there is a lot that Airtable doesn’t do that people would like. I prefer to see the glass as half full, especially as a month ago there wasn’t even a glass on the table.