Sending Airtable data to an external webhook

If you’d like to trigger a webhook in an external service (such as my favorite automation tool, 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:

1 Like

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.