API Airtable : guide complet de la Web API en 2026

À quoi sert l’API Airtable ?

Lorsque l’on parle d’« API Airtable », on fait généralement référence à la Web API.

Elle permet à un système extérieur à Airtable d’interagir avec vos bases de manière programmée.

Une application peut notamment :

• lire des records ;

• créer de nouveaux records ;

• modifier des données existantes ;

• supprimer des records ;

• filtrer et trier les données récupérées ;

• consulter la structure d’une base ;

• travailler avec plusieurs records en une seule requête.

Prenons un exemple simple.

Une entreprise gère son delivery dans Airtable mais possède une application client développée séparément. Lorsqu’un client ouvre son espace, l’application peut interroger Airtable pour récupérer ses projets, leurs statuts et les prochains livrables à afficher.

La logique est alors :

Application → Web API Airtable → données de la base

L’API devient l’interface entre Airtable et le reste du système.

Ce rôle doit être distingué de celui de la Webhooks API.

La Web API permet de lire ou modifier Airtable. La Webhooks API permet à une application d’être informée lorsqu’un changement se produit dans Airtable.

Les deux peuvent donc être complémentaires. Nous détaillons cette distinction dans notre guide sur les webhooks Airtable.

API, Automation, webhook ou Make/n8n : que choisir ?

Avant de créer une intégration API, la première question n’est pas « comment appeler Airtable ? », mais où doit vivre le processus ?

Cette distinction évite beaucoup d’architectures inutilement complexes.

Imaginons par exemple que le statut d’un projet passe à « À facturer » dans Airtable et qu’il faille créer un brouillon dans un logiciel de facturation.

Il serait possible de construire :

Airtable → système externe → API Airtable → API du logiciel de facturation

Mais si Airtable sait déjà détecter le changement, une architecture beaucoup plus directe peut suffire :

Automation Airtable → Run a script → API du logiciel de facturation

La Web API Airtable n’est donc pas nécessaire simplement parce qu’une API externe intervient dans le workflow.

C’est également le principe que nous détaillons dans notre guide des automatisations Airtable : garder le processus dans Airtable lorsqu’il peut y être exécuté proprement, puis ajouter des couches techniques uniquement lorsqu’elles répondent à une vraie contrainte.

Comment fonctionne la Web API Airtable ?

La Web API suit une architecture REST classique.

Une application envoie une requête à Airtable. Cette requête précise notamment :

• la base et la table concernées ;

• l’action souhaitée ;

• les autorisations utilisées ;

• éventuellement les données à créer ou modifier.

Airtable traite ensuite la requête et retourne une réponse au format JSON.

Les principales opérations correspondent aux méthodes HTTP habituelles :

GET permet de récupérer des données.

POST permet notamment de créer des records.

PATCH permet de modifier des records existants.

DELETE permet de les supprimer.

Il n’est donc pas nécessaire d’utiliser un connecteur Airtable spécifique pour intégrer la plateforme à une application. Tout environnement capable d’effectuer des requêtes HTTP peut théoriquement communiquer avec la Web API.

Filtrer plutôt que tout récupérer

Une erreur fréquente consiste à récupérer toute une table puis à filtrer les données dans l’application.

La Web API permet notamment de limiter les champs retournés, trier les résultats, utiliser une vue existante ou appliquer un filterByFormula.

Si une application n’a besoin que des projets actifs d’un client, mieux vaut demander ces données directement à Airtable que télécharger inutilement des milliers de records.

Cette logique devient importante pour les performances mais également pour limiter le nombre de requêtes API.

Comprendre la pagination

Une requête permettant de lister les records ne renvoie pas automatiquement toute une table.

Airtable retourne les résultats par pages pouvant contenir jusqu’à 100 records.

Une table de 450 records nécessitera donc plusieurs requêtes pour être récupérée entièrement.

L’API fournit un offset permettant de demander la page suivante jusqu’à ce qu’il n’y en ait plus.

Cette contrainte paraît anodine lors d’un premier test sur dix records, mais doit être intégrée dès le départ lorsqu’une application doit parcourir des volumes plus importants.

Utiliser les opérations en lot

Pour les créations, modifications ou suppressions, Airtable permet de traiter jusqu’à 10 records par requête.

Modifier 500 records ne doit donc pas nécessairement générer 500 appels API.

Il existe également des mécanismes comme performUpsert, qui permettent de rechercher puis créer ou mettre à jour un record dans une même logique.

Pour des imports unidirectionnels importants, la Web API classique n’est pas toujours la meilleure solution : la Sync API permet notamment d’envoyer des données CSV jusqu’à 10 000 lignes par requête.

L’objectif n’est pas d’utiliser systématiquement la même API, mais de choisir le mécanisme correspondant au processus.

Comment authentifier une intégration Airtable ?

Les anciennes API keys Airtable ne fonctionnent plus depuis février 2024.

Deux approches sont aujourd’hui particulièrement importantes.

Personal Access Token pour une intégration interne

Le Personal Access Token, ou PAT, convient lorsqu’une intégration est utilisée pour vous-même, votre entreprise ou un environnement client maîtrisé.

Lors de sa création, vous définissez :

• les permissions accordées au token ;

• les bases ou workspaces auxquels il peut accéder.

Un système qui doit uniquement lire une base n’a donc aucune raison de recevoir des droits de modification sur toutes les bases du workspace.

C’est une amélioration importante par rapport aux anciennes clés API.

Le principe à retenir est simple :

donner à une intégration uniquement les accès dont elle a réellement besoin.

Un PAT doit évidemment rester côté serveur ou dans un système sécurisé. Il ne doit jamais être intégré directement dans du JavaScript exécuté dans le navigateur d’un utilisateur.

OAuth pour une application utilisée par plusieurs clients

Si vous développez une application permettant à différents utilisateurs de connecter leur propre compte Airtable, utiliser votre propre PAT n’est pas la bonne architecture.

Airtable prévoit OAuth pour ce type d’intégration.

Chaque utilisateur peut alors autoriser explicitement l’application à accéder aux ressources nécessaires.

La différence est importante :

Intégration interne ou contrôlée → PAT

Produit ou intégration utilisée par différents comptes Airtable → OAuth

Sur Enterprise Scale, les organisations peuvent également utiliser des service accounts afin qu’une intégration critique ne dépende pas du compte personnel d’un collaborateur.

4 cas où l’API Airtable apporte réellement de la valeur

1. Construire une application au-dessus d’Airtable

Airtable peut servir de couche de données et d’administration tandis que les utilisateurs travaillent dans une application développée séparément.

Par exemple :

Airtable → données et opérations internes

Application web → expérience utilisateur

L’application peut utiliser la Web API pour récupérer ou modifier les informations nécessaires.

Cette architecture peut être pertinente pour un outil métier très spécifique ou lorsque l’expérience utilisateur doit dépasser ce que permettent les Interfaces et Portals Airtable.

Elle ajoute néanmoins une vraie couche applicative à maintenir.

Avant de développer un frontend, nous vérifions donc généralement si une Interface ou un portail Airtable ne répond pas déjà correctement au besoin. Notre guide sur la création d’un portail client avec Airtable présente les différentes approches possibles avant de passer au développement sur mesure.

2. Connecter une application métier à Airtable

Une application interne peut avoir besoin d’envoyer régulièrement des informations vers Airtable.

Imaginons par exemple un outil qui génère des estimations ou des analyses spécifiques.

Une fois le traitement terminé :

Application métier → Web API → mise à jour du dossier Airtable

L’application possède déjà la logique métier. L’API sert simplement à faire circuler la donnée vers Airtable.

3. Lire les données Airtable depuis un autre système

Une application peut également utiliser Airtable comme source de données.

Un système de reporting, un outil interne ou une application client peut par exemple récupérer uniquement les records et champs dont il a besoin.

Dans ce type d’architecture, il faut toutefois se demander à quelle fréquence les données doivent être actualisées.

Si l’application interroge Airtable toutes les quelques secondes uniquement pour savoir si quelque chose a changé, la Webhooks API peut devenir plus logique qu’un polling permanent.

Notre guide des webhooks Airtable détaille précisément cette distinction et explique quand associer Webhooks API et Web API.

4. Construire une intégration qui doit être réellement maîtrisée

Make ou n8n simplifient beaucoup d’intégrations et restent parfaitement adaptés à de nombreux workflows.

Une intégration directe via API devient intéressante lorsque l’application nécessite davantage de contrôle sur :

• la logique métier ;

• la gestion des erreurs ;

• les performances ;

• les retries ;

• l’authentification ;

• la journalisation ;

• l’expérience utilisateur.

Mais « plus de contrôle » signifie aussi plus de responsabilités techniques.

Une intégration API sur mesure n’est donc pas automatiquement plus robuste qu’un scénario Make bien conçu.

Elle ne le devient que si l’architecture, le code et son exploitation sont eux-mêmes correctement maintenus.

Quand ne pas utiliser l’API Airtable ?

C’est probablement le point le plus important de ce guide.

Si une Automation Airtable suffit

Un statut change et il faut :

• créer un record ;

• mettre à jour une donnée ;

• envoyer une notification ;

• générer une tâche ;

• exécuter une logique simple.

Commencez généralement par une Automation Airtable.

Ajouter une application externe uniquement pour modifier une autre table Airtable augmente le nombre de composants sans nécessairement améliorer le système.

Pour comprendre jusqu’où aller avec les fonctions natives avant d’ajouter une couche externe, consultez notre guide complet sur l’automatisation Airtable.

Si Airtable doit simplement appeler une API externe

Une Automation peut exécuter un script et effectuer une requête HTTP vers une autre API.

Pour un flux simple comme :

Projet validé → création d’un brouillon de facture

une Automation + Run a script peut être plus maintenable qu’une infrastructure externe complète.

Si Make ou n8n rendent l’orchestration plus simple

À l’inverse, vouloir tout coder directement n’est pas toujours une bonne décision.

Lorsque cinq applications doivent échanger des données, avec plusieurs branches et traitements intermédiaires, une plateforme d’orchestration peut offrir une meilleure visibilité qu’un ensemble de fonctions hébergées dispersées.

Le bon choix n’est pas le plus technique.

C’est celui que l’équipe pourra comprendre, superviser et maintenir dans deux ans.

Quelles sont les limites de l’API Airtable ?

La Web API est suffisamment performante pour de nombreux outils métier, mais Airtable n’est pas conçu comme une base de données applicative sans limites.

5 requêtes par seconde et par base

Airtable applique actuellement une limite de 5 requêtes par seconde pour chaque base, quel que soit le plan.

Une intégration qui dépasse cette limite reçoit une erreur 429.

Une architecture fiable doit donc prévoir :

• la limitation du nombre d’appels ;

• les opérations en lot ;

• des retries adaptés ;

• éventuellement du cache pour les lectures fréquentes.

Airtable applique également une limite de 50 requêtes par seconde pour l’ensemble du trafic utilisant les Personal Access Tokens d’un même utilisateur ou service account. En cas de dépassement de la limite, Airtable indique qu’il faut attendre 30 secondes avant de reprendre les requêtes.

Des quotas qui dépendent du plan

En plus de la limite par seconde, certains plans ont un quota mensuel.

Au moment de cette mise à jour :

Les limites par seconde continuent de s’appliquer sur Business et Enterprise Scale.

Pour une intégration appelée plusieurs milliers de fois chaque jour, ces quotas doivent donc faire partie du choix du plan et de l’architecture.

Airtable maintient les valeurs à jour dans sa documentation officielle sur les limites de la Web API.

Airtable ne doit pas devenir un backend par défaut

Pouvoir construire une application sur Airtable ne signifie pas qu’Airtable est la meilleure base de données pour n’importe quelle application.

Lorsque vous avez besoin de très gros volumes, d’un trafic important, de traitements transactionnels complexes ou de contraintes fortes de performance, une base applicative dédiée peut être plus adaptée.

Airtable peut alors rester utile comme outil opérationnel ou interface interne sans être placé au centre de toute l’architecture technique.

C’est un compromis important : exploiter la flexibilité d’Airtable tant qu’elle simplifie réellement le système, puis changer d’architecture lorsque les contraintes dépassent ce pour quoi la plateforme est conçue.

Comment démarrer proprement avec l’API Airtable ?

Nous recommandons de ne pas commencer par créer un token.

Commencez par dessiner le flux.

Par exemple :

Application → Airtable

ou :

Airtable → application

ou encore :

Airtable ↔ application

Demandez-vous ensuite qui déclenche le processus, quelles données doivent circuler et à quelle fréquence.

Cela permet souvent de découvrir qu’une Web API n’est pas nécessaire — ou au contraire qu’elle constitue précisément la bonne interface entre les deux systèmes.

Une fois l’architecture validée :

1. créez le mode d’authentification adapté ;

2. limitez les scopes et les ressources accessibles ;

3. identifiez les bases, tables et champs réellement nécessaires ;

4. testez d’abord une lecture et une écriture sur un environnement maîtrisé ;

5. gérez pagination, erreurs et limites avant de traiter de gros volumes ;

6. ajoutez des logs permettant de comprendre ce qui s’est passé en cas d’échec ;

7. rendez les opérations sensibles idempotentes pour éviter les doublons lors d’un retry.

L’objectif n’est pas simplement d’obtenir une première réponse 200.

Une intégration professionnelle doit également continuer à fonctionner proprement lorsque l’API ralentit, qu’une donnée manque, qu’un token change ou qu’une requête échoue.

Besoin de connecter Airtable à vos autres outils ?

HyperOps conçoit et fait évoluer des systèmes Airtable connectés aux autres outils de l’entreprise : automatisations natives, scripts, API, webhooks et architectures externes lorsque le besoin le justifie.

Nous partons du processus et de la circulation des données pour choisir l’architecture la plus simple capable de fonctionner durablement — sans ajouter Make, n8n ou du développement sur mesure lorsqu’Airtable peut déjà correctement exécuter le workflow.

Découvrir notre accompagnement Airtable.

Questions fréquentes sur l’API Airtable