Seconding the request for nodes selection in nested objects
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.
Crossing my fingers for an outgoing equivalent… Would save an awful lot of polling.
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
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?
I’ll check with our team and let you know!
@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
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.
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.
Seconding adding the ability to select a section of, or the entire JSON payload, to an input variable that a subsequent script action can process.
For my use case, there’s no way to anticipate exactly what a certain section of the payload will contain, so I can’t pull out individual fields & their values. I’ll need to be able to traverse the payload and figure out what I’m working with.
I think this is possible now - this screen shot shows the body received via a Tookan webhook where
custom_fields is a collection of JSON objects that contain a variety fields. One need only map this into a variable in your script action using
input.config() and away you go.
When I click on a “collection”-like area of the JSON payload, I only get the “Continue >” link to traverse farther into the JSON payload, not the option to Insert it into the input.config() variable…
Yes, that constraint still exists and it’s just dumb. At the very least a dot should give you the body.
Once the webhook is received, I tease out the id of the data source and then perform an immediate call back into the source of the webhook call, thus capturing the full body.
Hmmm…great little trick - I think it will work in my use case as well!
(But yes, still: Just pretty plz give us the ability to assign the payload to an input variable for crying out loud! )
Seconding (read: bazillioning) the request for the ability to assigning the full json payload to a variable. Shouldn’t be that hard, right.
I opened Is it possible to read a webhook data from a script? thinking what I wanted to do was rather straightforward, but no, Airtable doesn’t cease to surprise me with their design that looks like it’s been thought-out by a 2 months intern.
Accessing the whole payload from a script seemed like such a common need for anything a bit dynamic, but not, that’s not even possible.
I’m gonna build my own webhook outside of AT, not worth wasting my time on this.
LOL. I’ve said this repeatedly in very similar terms.