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