Airtable enables you to build and organize databases for just about any project you could imagine. The basic version is totally free to use and allows for real time collaboration with team members, making it an ideal data organization tool.    

In the example below, we're using the Call Webhook RuleSet in a flow to look up sales agents by zip code as stored in an Airtable database that we've created.   

Build your Airtable Database

In order to pull data into your flow using a Webhook, you'll first need to create an Airtable account and build your database

Below is our simple agent lookup database, which includes fields (equivalent to spreadsheet columns) for the agent's name, phone number, and zip code. 

Build your Flow

After you've created a database in Airtable, you're ready to build your flow. In our example below, we first asked the contact to send their zip code to look up their local agent. By using the Call Webhook RuleSet, we will send a request to Airtable to pull in the data from our database. 

*Note that look-ups in Airtable are case-sensitive. 

Setting up your Call Webhook RuleSet 

First, generate your Call Webhook RuleSet:

Next, choose 'GET' and enter your URL:

The components of your encoded URL can be found in your database's API documentation. Locate this documentation by clicking on 'HELP' in the upper right hand corner of your Airtable account:

Then, choose 'API Documentation':

On the following page, click 'show API key' in the upper right hand corner:

Then click on the 'Authentication' tab to the left of the screen:

On this page, you will find the information you need for your URL, Header Name, and Header Value.

Note that the Header Name is 'Authorization' and the Header Value is 'Bearer' + your unique API key. 

Configuring your URL

The URL is comprised of two parts. 

The first part is provided to you on your Airtable authentication page. In the case of our agent lookup database, the first part is: https://api.airtable.com/v0/app4bCiO5aU1AA5ir/Table%201   

The second part of the URL is a bit trickier, as it is encoded. Here's what it looks like for our agent lookup:
?filterByFormula=FIND(%22@flow.zip.category%22,%20%7BZip%7D)
 

When decoded, the URL is more readable:
?filterByFormula=FIND("@flow.zip.category", {Zip})
  

To create the second part of your URL, start with a query string with the field-value pair as follows:  ?filterByFormula=FIND  

From there, it's easier to write your URL with special characters and encode it afterwards. Write the expression within parentheses (). In the case of our agent lookup, this expression is ("@flow.zip.category", {Zip}) Here, @flow.zip.category refers back to the flow variable we created in our agent look up flow, while {Zip} refers back to the 'zip' field in the Airtable database.
  

When we put it all together, the decoded URL looks like this:

https://api.airtable.com/v0/app4bCiO5aU1AA5ir/Table%201?filterByFormula=FIND("@flow.zip.category", {Zip})  

The last step is to encode the URL. Encoding is necessary as it translates characters into a format that is accepted by web browsers and servers. Use a free URL encoder, such as this one, or translate it yourself using a table for character encoding, and here's the final result: 

https://api.airtable.com/v0/app4bCiO5aU1AA5ir/Table%201?filterByFormula=FIND(%22@flow.zip.category%22,%20%7BZip%7D) 


In the end, this is how the Call Webhook RuleSet looks for our agent lookup flow:

Evaluating External Variables

Once you've configured your Webhook, you can then use the @extra variable in your flow, which references variables returned from an external application via a Webhook.

To reference variables from your Airtable database, create a Split by Expression RuleSet that evaluates one of the returned values against a response rule. 

Here's a look at our Split by Expression RuleSet for our agent lookup flow:

Split by Expression Inputs:

A - The operand we used here is the expression @extra.records because 'records' is the key used by Airtable to reference what is essentially a row in our database. You can see the keys for your own database by viewing your Webhook events as detailed here

B - The response rule 'has only the phrase' works best for this particular use case. 

C - This represents the value(s) your response rules will attempt to match against the operand. In this example, we've used '[]', which indicates that no matching data was found in our Airtable database. 

D - The category in which contacts are placed if the the operand matches the corresponding response rule. Categories are pathways from which connections can be drawn to new steps, thus directing the contact onward. In this example, because no matching data was found, we want to inform our contact that their lookup did not result in an agent match.

The final piece of the flow is to send our contacts a message returning their agent's name and phone number:

As a reminder, we must use the @extra variable to reference the variables returned from our Webhook. In our example we used @extra.records.0.fields.[name of the field you created in Airtable] to reference the name and phone number of the agent. Recall that fields are equivalent to columns in a spreadsheet, which is what we must reference here. 

Here is our final result: 

We can test our flow using the simulator: 

Click on the 'webhook event' link in the simuator to view your Webhook event. 

For more detailed information about configuring and testing your Webhook, viewing Webhook events, and troubleshooting, click here. If you have any questions, send us a message via the support widget in the bottom righthand corner. 

Did this answer your question?