Límites de tasa

Límites de throughput de TwexAPI, manejo de 429, comportamiento de Retry-After y backoff seguro con paginación para trabajos en producción.

TwexAPI aplica límites de tasa para proteger la estabilidad de la cuenta y la capacidad de obtención upstream de X/Twitter. Diseña exportaciones, bucles de agentes y trabajos programados para respetar los límites en lugar de reintentar a velocidad máxima después de cada fallo.

Expectativas de throughput

TwexAPI está construido para cargas de trabajo en producción. Los benchmarks de marketing citan hasta 100 solicitudes por segundo por cliente en condiciones normales, pero tu límite efectivo depende del tipo de endpoint, el tier de la cuenta y la carga actual de la plataforma.

Trata el throughput publicado como un límite superior—no como un objetivo para cada integración.

Carga de trabajo	Orientación
Agentes interactivos	Llama a `explore` una vez por tarea, luego agrupa llamadas relacionadas de `twexapi_request`.
Exportaciones de seguidores	Pagina con cursores; agrega retraso entre páginas en cuentas grandes.
Trabajos programados	Escalonar horas de inicio; evita lanzar cada flujo de trabajo en `:00`.
Acciones de escritura	Mantén el volumen de escritura más bajo que el de lectura; requiere aprobación humana en agentes.

Cuando alcanzas un límite

Los límites excedidos devuelven HTTP 429 Too Many Requests. Algunas respuestas incluyen un header Retry-After (segundos hasta que sea razonable reintentar). Cuando esté presente, espera al menos esa cantidad de segundos antes de la siguiente llamada.

Forma típica de respuesta:

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

En MCP, twexapi_request expone el mismo estado dentro del resultado de la herramienta. Conserva cursores y filas completadas antes de hacer backoff.

Lista de verificación de recuperación

Detén el tráfico en ráfaga

Pausa bucles, flujos de Prefect, lotes de n8n o cadenas de herramientas de agentes que dispararon muchas solicitudes en una ventana corta.

Lee Retry-After cuando esté presente

Duerme el valor del header. Si falta, empieza con 5–15 segundos y aumenta en 429s repetidos.

Reanuda desde el último cursor

Reintenta la misma página, no la siguiente, para no omitir ni duplicar filas.

Reduce el QPS en estado estable

Agrega retraso entre solicitudes o reduce la concurrencia de workers antes de reiniciar el trabajo.

Ejemplo de backoff

Python con Retry-After opcional:

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

Los usuarios de Prefect pueden reflejar los mismos retrasos con retry_delay_seconds—consulta la guía de Prefect.

Patrones de diseño que evitan 429

Pagina en lugar de paralelizar lecturas idénticas

Obtener la página 1 veinte veces en paralelo no acelera una sola exportación. Recorre cursores secuencialmente a menos que los endpoints admitan explícitamente shards independientes.

Separa horarios de lectura y escritura

Las escrituras suelen tener límites prácticos más estrictos que las lecturas. Ejecuta publicaciones, likes y follows en una cola más lenta que búsquedas y consultas de perfil.

Cachea búsquedas estables

Almacena user_id, campos de perfil y metadatos de tweet cuando pasos downstream los reutilicen. Menos búsquedas duplicadas significan menos solicitudes contabilizadas.

Usa MCP `explore` con moderación

Las llamadas de descubrimiento también cuentan para el uso. Cachea el method y path elegidos durante la duración del trabajo.

Plataformas no-code y de agentes

Plataforma	Patrón
n8n	Agrega nodos Wait después de `429`; almacena el cursor en datos estáticos del flujo de trabajo.
Zapier	Usa replay integrado con retraso; alerta a ops en fallos repetidos.
Make	Enruta `429` a un módulo de sleep antes de reintentar el módulo HTTP.
Pipedream	Divide exportaciones grandes; limita pasos concurrentes por flujo de trabajo.

Los webhooks de plataforma (Catch Hook, Custom Webhook) reciben handoffs de agentes—no son flujos de eventos nativos de TwexAPI. Programa llamadas REST de seguimiento con backoff después de ingerir webhooks.

MCP vs REST

Ambas rutas comparten los mismos límites de cuenta y modelo de créditos. Un agente que hace bucle con twexapi_request sin retraso puede provocar 429 tan rápido como un bucle ajustado con SDK.

Para exportaciones largas en producción, prefiere REST directo o un SDK con política de reintento explícita sobre un bucle autónomo de agente.

Monitoreo de salud de límites de tasa

Registra estos campos por solicitud:

Estado HTTP
Ruta del endpoint
Cursor o índice de página
Número de intento de reintento
Retry-After cuando esté presente

Alerta cuando la tasa de 429 supere un umbral para una sola API key o flujo de trabajo.