Webhooks API
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. You can access the developer documentation for the Webhooks API here.
Overview
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 POST
request 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.
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 the following endpoints:
- Create a webhook
- Delete a webhook
- List webhooks
- Enable or disable webhook notification pings
- List webhook payloads
- Refresh a webhook
More technical information about each of these endpoints is available in the Webhooks API documentation.
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 a 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. A single OAuth integration can create up to 2 webhooks per base.
What are the rate limits? For example, is it per webhook hook or base?
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.
Will webhooks ever expire?
Yes, to help you clean up your unused webhooks, webhooks created with personal access tokens or OAuth access tokens will expire and be disabled after 7 days. Users can extend the webhook life while the webhook is still active by refreshing the webhook or listing payloads. The webhook life will be extended for 7 days from the refresh time.
Webhooks that were created with User API keys (now deprecated) will not expire, but can no longer be created.