Limites

L’API applique un petit nombre de bornes fixes. Elles sont choisies pour arrêter un script qui boucle, pas pour contraindre une intégration légitime. Quand une borne est atteinte, la réponse le dit par un statut et un code (Erreurs).

Les requêtes

Borne	Valeur	Au-delà
Requêtes par clé d’API	600 par minute glissante	429 api_key.rate_limited, Retry-After en secondes
Tentatives de connexion	Par adresse IP	429 auth.too_many_attempts, Retry-After
Corps de requête	5 Mo	413, code request.payload_too_large, details.reason: "FST_ERR_CTP_BODY_TOO_LARGE"
Corps d’un déclencheur webhook (POST /hooks/wf/{token})	256 Ko de JSON	413, code request.payload_too_large
triggerData d’un essai	256 Ko, comme le vrai webhook	400

La limite de débit est par clé : donnez à chaque intégration sa propre clé et aucune ne ralentira les autres. Les pièces jointes ne sont pas des corps JSON : elles se téléversent en multipart/form-data par POST /api/v1/messages/attachments, un fichier par requête, 25 Mo au plus (413 au-delà ; les exécutables et les scripts sont refusés en 400).

L’idempotence

Borne	Valeur
Longueur d’Idempotency-Key	1 à 200 caractères (400 idempotency.invalid_key sinon)
Mémoire d’une clé	24 heures
Réponse rangée	64 Ko ; au-delà, la réponse est servie mais pas mémorisée (Idempotency-Replayed: unsupported)

Voir Idempotence.

Les listes

Liste	limit par défaut	limit maximum
Exécutions, exécutions en attente, incidents, messages, fils, contacts, journaux, journal d’audit, cas d’évaluation	50	200
Approbations	50	100
Revue du matin	25	100
Notifications	30	100
Lignes de Tables (pagination par offset)	100	500

Un limit au-dessus du maximum est un 400 request.bad_request, pas un plafonnement silencieux. Les bornes exactes de chaque route sont dans la référence.

Les Tables

Borne	Valeur	Au-delà
offset de GET /api/v1/tables/{id}/rows	100 000	400 ; une page après la fin des lignes filtrées est tables.page_out_of_range
Filtres par requête (filter)	20 conditions	400
Lignes, colonnes, tables par instance	Fixées par l’instance ; lisez-les par GET /api/v1/tables/limits	409 tables.limit_reached, details.limit nomme la borne

Les opérations en masse

Opération	Borne
POST /api/v1/executions/cancel	200 identifiants d’exécution par appel
POST /api/v1/workflows/{id}/executions/cancel et …/retry-failed	limit de 1 à 200 par appel, 50 par défaut ; hasMore dit s’il faut rappeler
since de …/retry-failed	30 jours au plus, 24 heures par défaut
PUT /api/v1/workflows/{id}/test-messages	20 mails épinglés

Les clés d’API

Borne	Valeur
Nom	1 à 120 caractères
Portées par clé	1 à 20
Expiration (expiresInDays)	1 à 730 jours, ou aucune
Précision de lastUsedAt	Une minute

Workflows et exécutions

Le moteur d’exécution a ses propres bornes : combien d’exécutions d’un workflow peuvent être en vol à la fois (maxConcurrency), combien de temps une exécution peut rester active (executionTimeoutMs), combien de temps une attente peut durer. Chaque workflow rend les valeurs effectives et les plafonds de l’instance dans executionLimits, renvoyé par GET /api/v1/workflows/{id} ; demander plus que le plafond par PATCH /api/v1/workflows/{id} est un 409 workflow.execution_limit_invalid. Voir Exécutions et Configuration.