Incoming webhooks for automations ✨

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:

2 Likes

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.

4 Likes

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

3 Likes

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.

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.

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

1 Like

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?