---
title: "Limites de débit"
description: "Limites de débit TwexAPI, gestion des 429, comportement Retry-After et backoff sûr pour la pagination dans les tâches de production."
---

TwexAPI applique des limites de débit pour protéger la stabilité des comptes et la capacité de récupération X/Twitter en amont. Concevez les exportations, boucles d'agents et tâches planifiées pour respecter les limites au lieu de réessayer à pleine vitesse après chaque échec.

## Attentes de débit

TwexAPI est conçu pour les charges de production. Les benchmarks marketing citent jusqu'à **100 requêtes par seconde et par client** dans des conditions normales, mais votre limite effective dépend du type d'endpoint, du niveau de compte et de la charge actuelle de la plateforme.

Traitez le débit publié comme une borne supérieure — pas une cible pour chaque intégration.

| Charge de travail | Conseil |
| --- | --- |
| Agents interactifs | Appelez `explore` une fois par tâche, puis regroupez les appels `twexapi_request` associés. |
| Exportations d'abonnés | Paginez avec des curseurs ; ajoutez un délai entre les pages sur les grands comptes. |
| Tâches planifiées | Décalez les heures de démarrage ; évitez de lancer chaque workflow à `:00`. |
| Actions d'écriture | Gardez un volume d'écriture inférieur au volume de lecture ; exigez une approbation humaine dans les agents. |

## Lorsque vous atteignez une limite

Les limites dépassées renvoient HTTP **`429 Too Many Requests`**. Certaines réponses incluent un en-tête **`Retry-After`** (secondes avant qu'un retry soit raisonnable). Lorsqu'il est présent, attendez au moins ce nombre de secondes avant le prochain appel.

Forme de réponse typique :

```json
{
  "detail": "Rate limit exceeded. Try again later."
}
```

Sur MCP, `twexapi_request` expose le même statut dans le résultat de l'outil. Conservez les curseurs et les lignes complétées avant de ralentir.

## Liste de récupération

1. **Arrêter le trafic en rafale**

    Mettez en pause les boucles, flux Prefect, lots n8n ou chaînes d'outils d'agents qui ont déclenché de nombreuses requêtes en peu de temps.

2. **Lire Retry-After lorsqu'il est présent**

    Attendez la valeur de l'en-tête. S'il est absent, commencez par 5 à 15 secondes et augmentez sur des `429` répétés.

3. **Reprendre depuis le dernier curseur**

    Réessayez la **même page**, pas la suivante, pour ne pas sauter ou dupliquer des lignes.

4. **Réduire le QPS en régime permanent**

    Ajoutez un délai entre les requêtes ou réduisez la concurrence des workers avant de redémarrer la tâche.

## Exemple de backoff

Python avec `Retry-After` optionnel :

```python
import time
import requests

def call_with_backoff(fn, max_attempts=5):
    delays = [5, 15, 45, 120, 300]
    for attempt in range(max_attempts):
        response = fn()
        if response.status_code != 429:
            return response

        retry_after = response.headers.get("Retry-After")
        wait = int(retry_after) if retry_after and retry_after.isdigit() else delays[min(attempt, len(delays) - 1)]
        time.sleep(wait)

    return response
```

Les utilisateurs Prefect peuvent reproduire les mêmes délais avec `retry_delay_seconds` — consultez le [guide Prefect](/guides/prefect).

## Modèles de conception qui évitent les 429

### Paginer au lieu de paralléliser des lectures identiques

Récupérer la page 1 vingt fois en parallèle n'accélère pas une exportation unique. Parcourez les curseurs séquentiellement sauf si les endpoints supportent explicitement des partitions indépendantes.

### Séparer les plannings de lecture et d'écriture

Les écritures ont souvent des limites pratiques plus strictes que les lectures. Exécutez publication, likes et follows sur une file plus lente que la recherche et les consultations de profil.

### Mettre en cache les consultations stables

Stockez `user_id`, les champs de profil et les métadonnées de tweet lorsque les étapes en aval les réutilisent. Moins de consultations dupliquées signifie moins de requêtes comptabilisées.

### Utiliser MCP `explore` avec parcimonie

Les appels de découverte comptent toujours dans l'usage. Mettez en cache le `method` et le `path` choisis pour la durée d'une tâche.

## Plateformes no-code et agents

| Plateforme | Modèle |
| --- | --- |
| [n8n](/guides/n8n) | Ajoutez des nœuds Wait après `429` ; stockez le curseur dans les données statiques du workflow. |
| [Zapier](/guides/zapier) | Utilisez le replay intégré avec délai ; alertez les ops sur les échecs répétés. |
| [Make](/guides/make) | Routez `429` vers un module sleep avant de réessayer le module HTTP. |
| [Pipedream](/guides/pipedream) | Divisez les grandes exportations ; plafonnez les étapes concurrentes par workflow. |

Les **webhooks** de plateforme (Catch Hook, Custom Webhook) reçoivent les transferts d'agents — ce ne sont pas des flux d'événements natifs TwexAPI. Planifiez des appels REST de suivi avec backoff après l'ingestion du webhook.

## MCP vs REST

Les deux chemins partagent les mêmes limites de compte et le même modèle de crédits. Un agent qui boucle `twexapi_request` sans délai peut déclencher `429` aussi rapidement qu'une boucle SDK serrée.

Pour les exportations de production de longue durée, préférez REST direct ou un SDK avec politique de retry explicite plutôt qu'une boucle d'agent autonome.

## Surveillance de la santé des limites de débit

Journalisez ces champs par requête :

- Statut HTTP
- Chemin d'endpoint
- Curseur ou index de page
- Numéro de tentative de retry
- `Retry-After` lorsqu'il est présent

Alertez lorsque le taux de `429` dépasse un seuil pour une seule clé API ou un workflow.

## Pages associées

- [Gestion des erreurs](/guides/error-handling)
- [Authentification](/authentication)
- [Vue d'ensemble de l'API](/api-reference/overview)
- [Transfert MCP pour agents](/mcp/agent-handoff)