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 →

[kuovonne]

Bill.French:

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.

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.

Bill.French:

What am I missing?

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.

[Bill_French]

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

[kuovonne]

Bill.French:

we don’t have the ability to control the format of webhooks called by other platforms

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.

[Bill_French]

kuovonne:

you would have to resort to having input variables for each property and then manually reassembling the objects based on index.

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?

[kuovonne]

Bill.French:

And all unnecessary if Airtable would simply …

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.

[Bill_French]

kuovonne:

especially as a month ago there wasn’t even a glass on the table.

Okay, you are being polite and funny.

I’m being cranky because this is a simple concept - anticipate what other platforms are likely to do and accommodate such common and probable variants.

[Elias_Gomez_Sai]

This is great! I just realized this week :grinning_face_with_sweat:

[nodesk]

Seconding the request for nodes selection in nested objects

[Andrew_Nicklin]

Seconding the request to access the full payload (body) instead of just its children. This way we can handle any scenario through the script, including single records, arrays, etc.

In my case I want to do some minimal processing on payload arrival, but also JSON.stringify(body) and store it in a text column so I can do more processing based on other included data at a later date. One benefit of this is it allows me to add / change fields in the tools sending the payloads without having to immediately update the webhook-triggered airtable script (or target data tables structures) to handle them.

[Tuur]

Crossing my fingers for an outgoing equivalent… Would save an awful lot of polling.

Webhooks for Records Product Suggestions

Webhooks for records would be really useful. I’m heavily caching Airtable data on my own server via the API, and if Airtable could notify my server when a record is updated, created, or destroyed, that would help me invalidate the cached data and re-request it. Ultimately that would mean less calls from my server to the Airtable API, which I imagine would please Airtable. Are webhooks on the roadmap at all?