Limites de débit

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.

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 :

{
  "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

Exemple de backoff

Python avec Retry-After optionnel :

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.

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

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
• Authentification
• Vue d’ensemble de l’API
• Transfert MCP pour agents