Limitation de débit

Prev Next

Tulip applique des limites de débit aux API de tables afin d’offrir une expérience cohérente et fiable, et de garantir des performances et une disponibilité élevées sur la plateforme Tulip. La mise en place de ces limites de débit se fera par étapes sur toutes les instances Tulip au cours du printemps 2026.

Limites de débit pour les tables

Pour les formules Essentials, Professional et Enterprise, les limites de débit suivantes s’appliquent par table au sein d’un espace de travail.

Catégorie d’API Valeur de la limite de débit Points de terminaison
Écriture d'enregistrements 10 écritures par seconde par table POST /api/v3/tables/:tableId/records (createRecord) PUT /api/v3/tables/:tableId/records/:recordId (updateRecord) PATCH /api/v3/tables/:tableId/records/:recordId/increment (incrementRecord)
Suppression d'enregistrements 10 suppressions par seconde par table DELETE /api/v3/tables/:tableId/records (deleteRecords) DELETE /api/v3/tables/:tableId/records/:recordId (deleteRecord)
Lecture d'un enregistrement (individuel) 50 lectures par seconde par table GET /api/v3/tables/:tableId/records/:recordId (getRecord)
Lecture d'enregistrements (multiple) 10 lectures par seconde par table GET /api/v3/tables/:tableId/runAggregation (runAggregation) GET /api/v3/tables/:tableId/records (listRecords) POST /api/v3/tables/:tableId/exportDataset (exportDataset) GET /api/v3/tables/:tableId/count (countRecords)

:::(Info) NOTE: Some account plans will have custom configurations. This will be communicated to customers by Tulip Support or Customer Success Managers (CSM)
when applicable. If you are unsure, please contact support@tulip.co
:::

Feature rename

Prior to r383, Service Accounts were called "API Tokens".

Comment la limite est-elle calculée ?

Les limites de débit s’appliquent par (instance, table, opération). Tous les comptes de service d’une même instance partagent le même quota pour une table et une opération données — la création de comptes de service supplémentaires n’augmente pas la limite de débit effective.

Comment savoir si j’ai atteint la limite de débit ?

Les notifications concernant les limites de débit des tables s'affichent en haut de la page de chaque table.

Lorsque vous atteignez 80 % de la limite de débit, la bannière d’avertissement suivante s’affiche :Image{height="" width=""}Lorsque vous atteignez la limite de débit, la bannière d’erreur suivante s’affiche :Image{height="" width=""}Les bannières d’avertissement/d’erreur reflètent une fenêtre glissante de 7 jours. Une fois le seuil atteint, la bannière reste visible pendant 7 jours maximum après que votre utilisation est repassée en dessous du seuil. Les bannières affichent une date de « dernier dépassement » pour indiquer quand le seuil a été dépassé pour la dernière fois

Que faire si je dépasse la limite de débit ?

  • Examinez l’erreur 429. Le tableau et vous aideront à identifier pourquoi un compte de service donné est soumis à des limites de débit.
  • Regroupez les requêtes si possible. Par exemple, supposons que vous disposiez d’une application devant récupérer des données pour un ensemble d’enregistrements d’une table. Au lieu d’envoyer des requêtes individuelles pour chaque enregistrement, il est préférable d’envoyer une seule requête incluant tous les identifiants d’enregistrement (ou critères de filtrage) dont vous avez besoin, puis de traiter les résultats localement dans l’application.
  • Mettez les résultats en cache. Plutôt que d’envoyer des requêtes fréquentes, mettez en cache les données issues d’une requête précédente. Ensuite, actualisez les données soit à la demande (par exemple, lorsqu’un utilisateur souhaite explicitement actualiser les données dans une application), soit à intervalles réguliers respectant les limites de débit.
  • Assurez-vous que votre script gère correctement les requêtes soumises à une limitation de débit. Assurez-vous que votre script réessaie les requêtes des utilisateurs après une erreur 429.

:::(Info) NOTE: When calling an API via a connector function, the connector will automatically handle 429 responses, so no additional retry logic is required. External clients — scripts, automations hosted outside Tulip, or connectors calling Tulip's API from other platforms — must implement retry logic themselves.
:::

{{snippet.Avez-vous trouvé ce que vous cherchiez ?}}