Airtable Webhooks API Overview
  • 09 Sep 2022
  • 3 Minutes to read
  • Dark
    Light

Airtable Webhooks API Overview

  • Dark
    Light

Note
At this time, the Webhooks API feature is only available to Enterprise plan customers. Reach out to our sales team if your organization is interested in the Enterprise plan.


The Webhooks API allows developers to be notified in real-time about changes in their base that they care about, from newly created records, to a field being updated in an existing record, to a record moving in or out of a view. Read on to learn more about the basics of Webhooks API in Airtable.

If you are an enterprise user, you can access the developer documentation for the Webhooks API here, or directly from your base by clicking on the "Help" button in the upper right-hand corner while you are logged in on a laptop or desktop. This will bring up a list of additional resources. You will find a link to the API documentation at the bottom of that list.


Overview

For more information on our REST API for creating, retrieving, updating, and deleting records, take a look at this support article

Sometimes referred to as "reverse APIs," webhooks allow developers to simplify many common API workflows. Typically, API usage involves the process of having one software program ask for a specific set of information from another software program, known as a GET request. This process works great when an application regularly fetches data from Airtable’s APIs to understand the current state of a table or base. However, this can be somewhat tedious when attempting to keep information up to date, as records are added, updated, or removed. Oftentimes, fetching information from Airtable using GET results in superfluous calls that don't actually find any changes from previous requests.

Enter Webhooks! Webhooks allow the application you want information from (in this case, Airtable) to send a POSTrequest to the application where you want the information to be used. This eliminates unnecessary API calls because the POST request is only sent based upon the Webhook's specifications.

NOTE

Depending upon the workflow you are trying to build, Webhooks may not always be the best option. You may also want to consider implementing our "Run a script" automation action.


Endpoints

Airtable's Webhooks API currently contains 5 endpoints:

  • Create a webhook
  • Delete a webhook
  • List webhooks
  • Enable or disable webhook notification pings
  • List webhook payloads

More technical information about each of these endpoints is available in the Webhooks API documentation.


Support guidance

If the troubleshooting steps outlined in this article do not help to resolve your issue, then feel free to reach out to our Support team. Our Support team is here to help you if you have issues using Webhooks but cannot build out new integrations for your team.
Please include the following information when you submit your help request :

  • The full API request (Please omit your secret API key)
  • Any error messages you are receiving
  • Relevant and specific context around the particular issue you are encountering
NOTE

If you were part of our Webhooks API beta testing group, then please consult our deprecation notice for more information on how to translate specifications and more.

FAQs

When should I use the Webhooks API?

The Webhooks API is an advanced API feature. It can be used for building custom automations and data replication workflows. However, some use cases may be more straightforward to implement and better suited to use an Automation with the Run Script Action to make a POST request to your desired endpoint.

How many webhooks can I register?

There is a limit of 10 webhooks per base.

What are the rate limits? For example, is it per webhook hook, base, or API key?

All webhook endpoints, including the GET Payloads endpoint, will follow our standard rate limits of 5 requests per second per base.

Can I filter out changes made by an Airtable Automation (or another source)?

Yes, this is supported by the fromSources filter parameter in the specification.

How long are payloads available to be retrieved?

Payloads are retained for 7 days.

Does the ping include the change payload?

No, the change payload must be fetched from the GET
Payloads endpoint.

Are the order of notification pings guaranteed?

The notification ping order is not guaranteed however the list of payloads from the GET Payloads endpoint does have a stable order. It's also worth noting that a single notification ping may represent several changes in the base so even if there are many changes in the base at once, we may only send out one ping per hook.


Was this article helpful?