Handling incoming webhooks in Airtable Automation

I was working on a project this week that presented an problem with the way Airtable automations handle incoming webhooks.

The recent addition of the automation trigger “When webhook received” is really welcome, but its implementation needs some improvement, which will, no doubt, happen over time.
The scenario I had was this:

  • When an invoice is finalised in Stripe, send the invoice data to Airtable

Stripe has a huge range of events that it can notify other systems about via webhooks, so I thought the set up of this should be straightforward. I had already planned to have my automation as:

  • When webhook received, run script

Although you could use other automation actions such as “create record”, the Stripe payload structure is very nested and I knew Airtable automations don’t yet have an iterator component (like Zapier or Make), I knew from the start that a script would be required.

What I did not know is that Airtable doesn’t currently allow you to pick an arbitrary element of the nested payload to pass into your script. I wanted the main data object, but Airtable forced me to click through the nested structure to choose an end node/element. Not what I wanted.

I thought about using Make.com, which I knew would resolve the issue, but bringing another tool into the solution didn’t feel right.

The solution - One element I could easily get from the Stripe payoad was the Stripe invoice ID. So, my script action takes in this ID and then makes a call to the Stripe API to get that invoice in full.

When you think about it for more than 5 seconds, it feels like this is a crazy solution:

  • get all of data sent to you via an incoming webhook
  • get one element of that data
  • make an API call to get all of the same data again
  • do the thing that you original set out to do

And it is crazy. But I have kept the solution wholly in Airtable and there’s no performance issues (script timeouts for example).


Reminds me of @bfrench Bill’s complaint about the complexity of no-code solutions. Since incoming webhooks have some significant limitations, the code for them can be prone to the same issues.

But your technique of keeping it all in Airtable sounds great. Only two moving parts, even if there is a lot of back-and-forth between the parts.

@JonathanBowen, as usual, I thoroughly enjoyed your comments about inbound webhooks in Airtable.

I wrote extensively about this in the former community and spent 30 minutes trying to find the references without success. As one user accurately points out and I agree:

I digress; luckily, I have a separate index of my [former] Airtable Community posts in Mem and I was able to locate a key observation.

The entire point of inbound webhooks is to avoid middleware that increases solution complexity and latency.

In any case, your approach is the only practical remedy to a poorly-designed webhook listener architecture if you want to unify the tech stack.


I just posted a tip for working around this data access issue with incoming webhook data:

Hoping that this might help!