Intégration API Airtable
Nous développons votre connecteur Airtable
Nous branchons Airtable à votre produit : l'ERP alimente la grille du jour, l'ops filtre sur place, le statut Expédié revient dans votre application.
- Équipe produit senior
- connecteurs Airtable en production
- du cadrage au monitoring
À quoi sert l'API Airtable et pourquoi l'intégrer dans votre plateforme ?
Airtable est une base collaborative que les équipes métier construisent elles-mêmes. Son API permet à votre application d'y pousser des records, de lire une grille, et de réagir quand un statut change. On l'intègre pour que tout cela vive dans votre produit : grille « colis du jour » alimentée par l'ERP, statut Expédié revenu dans l'application, formulaire interne devenu ticket, catalogue léger lu par le site via un cache. Airtable reste un back-office temporaire ; votre SI reste la source de vérité. On ne laisse pas la base devenir le cœur du système.
Ce que Airtable change dans votre plateforme
Grille ops alimentée par l'ERP
Les commandes du jour arrivent dans Airtable. L'ops filtre sur place, sans export Excel mort du lundi.
Statut Expédié revenu dans le produit
Le statut Expédié revient dans votre SI. Le dossier se met à jour, sans second process parallèle.
Formulaire interne devenu ticket
La demande saisie dans Airtable crée l'objet métier avec un identifiant de rapprochement. Pas de doublon à chaque synchronisation.
Catalogue léger lu par le site
L'équipe édite dans Airtable, le site lit via un cache. Back-office temporaire, pas un SI caché derrière le front.
Ce que ça change dans votre produit
La technique au service d'un résultat mesurable : grille depuis l'ERP, statut revenu, back-office temporaire sous contrôle.
L'ops travaille dans la grille, pas dans un export
L'ERP pousse les commandes. La vérité reste dans le produit ; Airtable est la vue opérationnelle.
Le dossier se met à jour sans ressaisie
Le statut Expédié revient dans votre application. Pas de second process entre la grille et le SI.
Le site reste fluide pendant que le métier édite
Le catalogue est lu via un cache, pas en live à chaque visite. L'équipe peut modifier Airtable sans casser le front.
Airtable reste remplaçable
Les identifiants métier sont figés côté produit. Le jour où le métier mature, on bascule sans reconstruire le SI.
Comment nous livrons votre connecteur Airtable
Cadrage
Où Airtable entre dans votre produit : grille ops, retour de statut, formulaire, catalogue. Bases, PAT ou OAuth, plan et quota. Ressources bornées.
IDs
Mapping vers vos objets métier : table IDs, champ de rapprochement record id ↔ id métier. Les noms de table ne sont pas des clés.
Développement
Connecteur branché sur la poussée ERP et le retour de statut. Rate limiter < 5/s/base, cache de lecture, refresh webhook < 7 jours.
Monitoring
429, webhooks disabled, quota mensuel Team. Alerte avant la coupure, pas après la grille vide.
Ce que l'API apporte à votre plateforme
- Pousser la grille depuis l'ERP
- Records créés et mis à jour avec id métier. L'ops filtre dans Airtable, le produit reste maître.
- Ramener le statut vers le SI
- Webhooks ping puis list payloads : Expédié met à jour le dossier. Ce n'est pas un Stripe, le pull consomme le 5/s.
- Alimenter le site via un cache
- Lecture catalogue sous 5 req/s. Le live à chaque page vue est interdit par le contrat.
- Tenir file et refresh en production
- Limiteur client, sleep 30 s sur 429, refresh webhook avant 7 jours. Sans ça, la grille se vide en silence.
Le vocabulaire de l'API Airtable
- 5 req/s
- Par base. Un 429 impose d'attendre 30 secondes, pas 1 s. Un burst de 20 appels coûte une demi-minute d'arrêt. La file doit anticiper le 5/s.
- Ping + pull
- La notification webhook n'embarque pas l'enregistrement. Il faut GET payloads, donc consommer le 5/s une seconde fois. Ce n'est pas un événement Stripe.
- 7 jours
- Expiration des webhooks PAT/OAuth. refresh ou list payloads remet 7 jours. Un webhook oublié meurt silencieusement. Job et alerte disabled.
- 2 webhooks OAuth / base
- Une app Marketplace ne pose pas un webhook par table à volonté. 10 webhooks max par base tous régimes confondus.
- Table ID
- Le nom de table change, l'ID non. Figer les IDs en configuration. Un connecteur calé sur le libellé casse au premier rename ops.
- PAT
- Personal Access Token, lié à l'utilisateur. Un départ salarié casse l'intégration. Compte de service ou OAuth pour le client. api_key query : mort au 1er février 2024.
Les contraintes réelles de l'API Airtable
Le 429 Airtable dure 30 secondes
Ce n'est pas un retry dans 1 s. Un burst mal cadré arrête toute la base une demi-minute. Le limiteur côté client anticipe le 5/s, il ne se contente pas de réagir.
Le webhook est un ping, pas un payload
Il faut list payloads, donc encore du 5/s. Concevoir le handler comme un Stripe (tout dans le POST) produit des syncs muettes ou des 429 en cascade.
7 jours, sinon silence
Refresh obligatoire, alerte si disabled. 2 webhooks OAuth par base : une app ne se multiplie pas par table. C'est une contrainte d'app, pas de tableur.
Team 100k, Business sans cap mensuel
Business n'enlève pas les 5/s. Un poll 1/min × N tables brûle le Team. Le live utilisateur passe par un cache, toujours, sinon la grille se fige au premier 429.
PAT Airtable ou OAuth / compte de service ?
Deux régimes d'accès. Le PAT va vite en recette. En production chez le client, le départ d'un salarié ne doit pas couper le connecteur.
| Critère | PATUtilisateur | OAuthApp / service |
|---|---|---|
| Mise en service | Quelques minutes | App, scopes, ressources |
| Qui porte le token | Un salarié | L'intégration |
| Départ de l'employé | Le connecteur casse | Sans effet |
| Webhooks / base | Jusqu'à 10 | 2 par intégration OAuth |
| 50 req/s toutes bases | Oui, par utilisateur | Selon le compte d'app |
| api_key en query | Mort depuis le 01/02/2024 | Jamais été le modèle |
| Le bon cas | Script interne, recette | Produit, client, Marketplace |
Le grantor doit être éditeur, le token data.records:write, la base dans les ressources. Trois conditions, pas une. Nous bornons les scopes à la base utile, pas all workspaces.
Ce que nous mesurons sur une intégration Airtable
Les autres outils de productivité
Si Airtable n'est pas le back-office temporaire de votre produit, ces options se discutent au cadrage.
AirtableNous développons votre connecteur AirtableCette page
SlackL'alerte et l'action, quand la grille n'est pas le bon canal.
JiraLe ticket et le workflow, quand Airtable ne trace plus assez.
NotionLe wiki et la page, quand la donnée n'est plus une grille.
MetabaseNous développons votre connecteur MetabaseOn combine Airtable avec
La stack autour d'Airtable quand on le branche dans un ERP ou un site.
Airtable : vos questions
On la branche sur vos touchpoints produit : poussée de commandes depuis l'ERP, retour de statut Expédié, formulaire vers ticket, catalogue lu par le site. Techniquement : auth Bearer (PAT en recette, OAuth ou compte de service en prod), table IDs et champ de rapprochement, rate limiter sous 5 req/s, webhooks ping puis pull avec refresh avant 7 jours. La partie sensible n'est pas POST records, c'est le parcours produit, la file et le job de refresh.
C'est le contrat public : 5 req/s par base, 50 req/s toutes bases pour les PAT / comptes de service d'un même utilisateur. Un 429 impose d'attendre 30 secondes. Un burst de 20 appels coûte une demi-minute d'arrêt sur la base. Team ajoute 100 000 appels/mois par workspace ; Business enlève ce cap, pas les 5/s. Un écran qui lit Airtable en live a besoin d'un cache. La file anticipe le 5/s, elle ne se contente pas de réagir au 429.
Ce n'est pas un Stripe. La notification est un ping. Les diffs se tirent avec list payloads, donc encore du 5/s. Expiration 7 jours (PAT/OAuth) : refresh ou list payloads remet 7 jours. Max 10 webhooks par base, 2 par base et par intégration OAuth. Un webhook oublié meurt silencieusement (disabled). Nous posons le job de refresh, l'alerte, et nous ne concevons pas une app Marketplace avec un webhook par table.
Non. Fin de dépréciation au 1er février 2024. Un connecteur qui passe api_key en query est déjà mort. Auth actuelle : Authorization Bearer, PAT ou OAuth, scopes et ressources (bases / workspaces) configurés sur le token. Pour écrire : grantor éditeur, scope data.records:write, base dans les ressources. Trois conditions. Un PAT lié à un salarié n'est pas un connecteur client, et nous le remplaçons avant la prod.
Un premier flux utile, typiquement pousser des commandes depuis l'ERP vers une grille et ramener un statut, se livre en deux à trois semaines. Une chaîne complète avec webhooks, cache site, plusieurs tables et OAuth demande plutôt six à huit semaines. La durée dépend surtout des touchpoints à brancher, du mapping d'IDs et du volume sous 5/s. Nous cadrons le périmètre en amont et donnons une estimation ferme avant de commencer.
Un projet d'intégration Airtable ?
Parlons-en. 30 minutes pour cadrer où Airtable entre dans votre plateforme (grille ops, retour de statut, catalogue) et si le volume tient sous 5 req/s.
Parler de mon projet Airtable