Skip to main content
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
JavaScript

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
JavaScript
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.

¿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 o Discord para consultar infraestructura dedicada y planes personalizados.

Próximos pasos

  • Paginación: obtiene conjuntos grandes de datos respetando el límite.
  • Códigos de error: referencia de respuestas 400, 401, 403, 404, 429 y 500.