Instantly trigger a automation from Airtable (i.e. sending Airtable data to an external webhook such as

If you’d like to trigger a webhook in an external service (such as my favorite automation tool Make), you can easily do this by creating a formula field or a button field that combines the webhook URL + any parameters that you want to send to the webhook.

So, for example, if your webhook URL is, and you want to send it your RecordID, you would create a formula field or a button field with a formula that looks like this:

"" & RECORD_ID()

When you use Make, you only need to send it the Record ID, because using the Airtable: Get A Record module, you can easily pull in any other fields that you want from that record.

However, if you needed to send additional fields to your webhook, your formula would look something like this:

"" & RECORD_ID()
"&email=" & ENCODE_URL_COMPONENT({Email Field})
"&name=" & ENCODE_URL_COMPONENT({Name Field})

But this technique will always open up a new browser tab which will show you the webhook response.

Often times, this is exactly what you WANT to happen. You will often WANT your users to see the webhook response, especially if it’s a webhook response that you have specifically customized for the user to see.

And Make gives a tremendous amount of control over webhook responses with their webhook response module. You could even create an entire HTML page as a response! For example, for lengthy automations, I will give my users a webhook response that gives them the estimated time of completion for their automation which is calculated based on the number of records that need to be processed.

But what if you DON’T want to open up a separate browser tab when you trigger the external webhook?

For those of you who would like to trigger an external webhook WITHOUT opening up a browser window, you can do this by triggering an automation in Airtable with the “Run Script” action.

NOTE: When performing a “Run Script” action, you are required to set your input variables in the left margin (see screenshots below). So, for example, in the 2 screenshots below, you can see that I’m referring to my Record ID as myRecord.

To send just the Record ID to your webhook, your script would look something like this:

let config = input.config();
let url = `${config.myRecord}`;

(Remember that you have to pre-define “myRecord” in the left margin, as you will see in the first screenshot below.)

To send multiple fields to your webhook, your script would look something like this:

let config = input.config();
let url = `${config.myRecord}&email=${}&name=${}`;

Once again, remember that those 3 input variables are defined in the left margin. See screenshot #2 below.



Hope this helps! :smiley:


Love this idea! :clap:

1 Like

The Run Script action + Airtable Get module in Make proved to be very handy in a lot of integrations I’ve done!! And echoing @JonathanBowen - loved the HTML page as a response idea. Thanks @ScottWorld!

1 Like

Thanks, @JonathanBowen and @jhi! :smiley: :raised_hands:

For further clarification on this topic:

When using a custom webhook in Make, below is an example screenshot of what the very beginning of your scenario might look like in Make… and then you could add in a whole bunch of other modules to do whatever you want to do in Airtable or other external apps.

Note that you only need to send the Record ID to Make, because you can use the Airtable Get a Record module to grab all the field information that you need from Airtable.

1 Like

I feel like I had a conversation somewhere with someone about sending only the record ID to Make when calling the webhook, versus sending all the necessary field values up front.

Sending only the record ID and having Make find the record to get the rest of the field values is usually easier when first getting used to this type of integration. Figuring out the formula or script for the url is very simple. You also do not need to worry about how much data there is.

On the other hand, sending only the record ID does have some disadvantages.

  • Overall execution time takes longer because you need to have an additional round trip of Make calling the Airtable API to and then the Airtable API returning the field values to Make.
  • The Get a Record module costs an additional operation. (Although operations are fairly cheap.)
  • The Make scenario is tied to a specific base and will not work with other versions of the base, such as restored snapshots or a sandbox version.
  • Changes to the fields, such as field type of select options, may need to be manually adjusted in the Make scenario, not just the base itself.

My current method of calling a Make webhook involves sending all the necessary information with the initial call to the webhook. I also put the Webhook response at the end of my scenario so that it report on whether or not the scenario executed successfully. When I call the webhook from a script, I also like to throw in additional meta information, such as the base, table, record, and user calling the webhook, which can be useful when debugging.


@ScottWorld I can only get this to work if my Airtable script saves the record ID in a variable first. My automation is triggered when the user clicks an interface button. Any idea why I have to take this extra step?

@JeanHT Welcome to the community.

You issue is because you are using straight quotes (') around your url.

If you examine the screenshot in the earlier post carefully, you will see that it uses back tics (`) instead. It’s a JavaScript thing.


Goodness. You absolutely right! Tired eyes today.

Thank you.

@ScottWorld would you consider adding a section on how to send structured data in bundles/arrays?

Hi @Ricardo!

Sorry, I’m not sure I understand your question!

Thank you so very much for this! It was the missing link I was looking for the last couple of days. As a result I have finally setup my first little mini script in airtable and webhook in make. :slight_smile:

1 Like

That’s great to hear! You’re welcome! :smiley:

So, this week I noticed an email from Airtable that my Zapier connections for some of my clients were revoked due to high volume of API calls. I noticed that @bfrench had posted in the Airtable Community Forum that my triggers of “Airtable Record Updated” is causing a ton of polling. It seems that the solution, according to @bfrench is to use a webhook. So, am I correct that this send webhook structure with a Run a Script action in Airtable Automations is the way to go? I’m thinking about the daunting task of switching all of my Zapier triggers that start with polling.

I defer to other opinions, but I think it’s the best way to mitigate API calls.

It is a very different and tedious set of changes to embrace event-driven architectures. You should try just one and then monitor the difference.

I don’t understand what you mean by “Revoked”.
I was thinking along the same lines, but concerned that eventually you run up against airtable’s hard limit on automation runs, which applies to all plans (25000/Team,100000/Business). Maybe I’m just overthinking.

@billh I got an email from Airtable that said: " The Zapier third-party integration’s access to your Airtable account has been automatically revoked by Airtable due to security concerns around refresh token usage."

Thanks, I’m not sure I’ve got enough background to understand that, but I appreciate you sharing.

This is related to a platform outage that day. I believe the issue was resolved after 10 hours. This is unrelated to Airtable’s API ceiling.

Correct. You need to juggle that limit as well. However, there’s a good chance that the number of runs you consume from data changes is far less than the benefits of avoiding polling. If you have so many changes ongoing in your data set, then Airtable is on solid ground to assert a higher price - ergo, an upgrade in service level with more runs.

There’s almost no universe where polling is better than event-driven automation.