---
title: "Límites de tasa"
description: "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:

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

1. **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.

2. **Lee Retry-After cuando esté presente**

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

3. **Reanuda desde el último cursor**

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

4. **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:

```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
```

Los usuarios de Prefect pueden reflejar los mismos retrasos con `retry_delay_seconds`—consulta la [guía de Prefect](/guides/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](/guides/n8n) | Agrega nodos Wait después de `429`; almacena el cursor en datos estáticos del flujo de trabajo. |
| [Zapier](/guides/zapier) | Usa replay integrado con retraso; alerta a ops en fallos repetidos. |
| [Make](/guides/make) | Enruta `429` a un módulo de sleep antes de reintentar el módulo HTTP. |
| [Pipedream](/guides/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.

## Páginas relacionadas

- [Error Handling](/guides/error-handling)
- [Authentication](/authentication)
- [API Overview](/api-reference/overview)
- [Agent MCP Handoff](/mcp/agent-handoff)