> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sorsa.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Límites de solicitudes

> Sorsa aplica un límite sencillo: 20 solicitudes por segundo en todos los planes. Aprende cómo funciona y cómo respetarlo.

Sorsa aplica un límite de frecuencia común para mantener el servicio rápido y estable. No hay niveles por endpoint ni ventanas móviles: basta con diseñar tu integración teniendo en cuenta un único límite.

## La regla: 20 solicitudes por segundo

Cada clave de API admite **20 solicitudes por segundo**. Es el único límite de frecuencia: no hay límites por endpoint, ventanas de 15 minutos, reinicios por hora ni diferencias entre planes.

Coordina la frecuencia conjunta de todos los procesos que comparten una clave y gestiona las respuestas `429` incluso cuando regulas las solicitudes localmente.

Ten en cuenta estos detalles:

* El límite se aplica **por clave de API**, no por dirección IP. Si tienes varias claves, cada una dispone de sus propias 20 solicitudes por segundo.
* **Cada solicitud cuenta igual.** Una llamada a `/info` y otra a `/tweet-info-bulk` con 100 publicaciones consumen una solicitud cada una.
* **No es una ventana deslizante.** El contador se reinicia cada segundo. Si envías 20 solicitudes en `T+0.00`, puedes enviar otras 20 en `T+1.00`.

## Qué ocurre al superar el límite

Si envías más de 20 solicitudes en un segundo, las que excedan el límite recibirán `429 Too Many Requests`. No se pierden datos ni se penaliza la clave. Espera al siguiente segundo y vuelve a intentarlo.

No se devuelven encabezados `x-ratelimit-remaining` ni `x-ratelimit-reset`. Como el contador se reinicia cada segundo, estos encabezados añadirían complejidad con poca utilidad práctica.

## Cómo respetar el límite

La mayoría de las cargas habituales no se acercan a las 20 solicitudes por segundo. Para trabajos por lotes o conjuntos grandes de datos, puedes aplicar estos métodos.

### Opción 1: Espera fija entre solicitudes

En un único proceso secuencial, una pausa de al menos 50 ms después de cada respuesta limita la frecuencia de envío. Deja una pausa mayor para disponer de margen. Si varios procesos comparten una clave, utiliza un limitador común: las pausas independientes de 50 ms no garantizan un total de 20 solicitudes por segundo.

**Python**

```python theme={null}
import time
import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.sorsa.io/v3"

usernames = ["elonmusk", "naval", "paulg", "vaborsh"]

for username in usernames:
    response = requests.get(
        f"{BASE_URL}/info",
        params={"username": username},
        headers={"ApiKey": API_KEY},
        timeout=30,
    )
    response.raise_for_status()
    print(response.json()["display_name"])
    time.sleep(0.05)  # 50ms between requests
```

**JavaScript**

```javascript theme={null}
const API_KEY = "YOUR_API_KEY";
const BASE_URL = "https://api.sorsa.io/v3";

const usernames = ["elonmusk", "naval", "paulg", "vaborsh"];

for (const username of usernames) {
  const res = await fetch(`${BASE_URL}/info?username=${username}`, {
    headers: { ApiKey: API_KEY },
  });
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  const data = await res.json();
  console.log(data.display_name);
  await new Promise((r) => setTimeout(r, 50)); // 50ms between requests
}
```

### Opción 2: Reintentar tras un 429

Si prefieres enviar solicitudes a máxima velocidad y reaccionar al límite, detecta las respuestas `429` y reintenta tras una breve espera.

**Python**

```python theme={null}
import time
import requests

def fetch_with_retry(url, headers, max_retries=3):
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers, timeout=30)

        if response.status_code == 429:
            time.sleep(1)
            continue

        response.raise_for_status()
        return response.json()

    raise Exception("Rate limit: max retries exceeded")
```

**JavaScript**

```javascript theme={null}
async function fetchWithRetry(url, headers, maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const res = await fetch(url, { headers });

    if (res.status === 429) {
      await new Promise((r) => setTimeout(r, 1000));
      continue;
    }

    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return await res.json();
  }
  throw new Error("Rate limit: max retries exceeded");
}
```

En la práctica, conviene combinar ambos métodos: una pequeña pausa para reducir los `429` y reintentos para gestionarlos cuando aparezcan.

## Los endpoints por lotes reducen la necesidad de velocidad

Antes de optimizar la velocidad, comprueba si puedes reducir el número de solicitudes:

* `/info-batch` obtiene hasta 100 perfiles en una solicitud.
* `/tweet-info-bulk` obtiene hasta 100 publicaciones en una solicitud.

Una solicitud por lotes cuenta igual que una normal tanto para el límite de frecuencia como para la cuota. Para muchos usuarios o publicaciones, los lotes casi siempre son más eficientes que las consultas individuales en paralelo. Consulta más patrones en [Optimización del uso de la API](https://docs.sorsa.io/es/optimizing-api-usage).

## ¿Necesitas un límite superior?

Si necesitas mantener más de 20 solicitudes por segundo, por ejemplo 100 o más para supervisión en tiempo real, contacta mediante [Talk to Sales](https://api.sorsa.io/talk-to-sales) o [Discord](https://discord.com/invite/uwAefKCj7X) para consultar infraestructura dedicada y planes personalizados.

## Próximos pasos

* [Paginación](https://docs.sorsa.io/es/pagination): obtiene conjuntos grandes de datos respetando el límite.
* [Códigos de error](https://docs.sorsa.io/es/error-codes): referencia de respuestas 400, 401, 403, 404, 429 y 500.