Incoming webhooks for automations ✨

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?

1 Like

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.

2 Likes

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.

2 Likes

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?

2 Likes

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.

11 Likes

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.

4 Likes

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

2 Likes

Seconding the request for nodes selection in nested objects

1 Like

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.

2 Likes

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

2 Likes

I’m with Andrew – getting the entire payload body will enable us to process it with a script.

This would be a relatively small fix with a big impact.

Hi everyone, I wanted to share that we now support application/x-www-form-urlencoded payloads.

7 Likes

Hi @Jason , are there plans for record webhooks that are separate from automations? That I’m limited by the automations quota is a big limiting factor

@Jason Any chance of incoming webhooks supporting GETwith url parameters?

1 Like

I’ll check with our team and let you know!

1 Like

@kuovonne It’s not something we have planned currently, but we are gathering feedback for the future if/when we build that out. If you have any unique context or applications for this to share I’m happy to pass it along to our developers :+1:

3 Likes

The support article leaves a lot to be desired. It explains how to test a webhook, but not how to actually apply it in an Airtable context.

Can I, for example, trigger an automation when a colleague clicks a URL in an email (with prefilled parameters)?

Webhooks must be called via a script where you can control the request type. Unfortunately a plain URL won’t work because the webhook call must be a POST request. URLs that pass data in the URL itself are sent via a GET request. A quick test to confirm this theory returned a 404 error.

2 Likes

The workaround - it should be pretty straightforward to create a proxy service that converts the GET into a POST. If asked I would build this in AutoCode or maybe Nginx.

2 Likes