Límites de velocidad
La API programática aplica un límite de solicitudes sencillo por cuenta, además de la cuota de créditos mensual. En esta página se explica en qué consiste dicho límite, cómo se calcula y cómo reducir el número de solicitudes de forma adecuada.
El
| Configuración | Valor |
|---|---|
| Ventana | 60 segundos continuos |
| Número máximo de solicitudes | 60 por cuenta de facturación (período móvil) |
| Contado | Reciente exitoso llamadas con tarifa por minuto, 429s, y 500s una vez que se haya aprobado el plan de autorización (ventana móvil en el servidor). 401 / 403 no cuentan para este límite. |
| Fuente | Límite predeterminado del producto: 60 solicitudes por minuto por cuenta. |
En la práctica: una solicitud por segundo de media, con picos de hasta 60 solicitudes permitidos en cualquier intervalo de 60 segundos.
Cuando se supera el límite, la siguiente solicitud devuelve:
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
{
"success": false,
"error": "Rate limit exceeded. Max 60 requests per minute."
}
La solicitud 429 queda registrada, lo cual está bien: caduca al salir del intervalo de 60 segundos, como cualquier otra solicitud.
Cómo funciona la ventana
El limitador es una ventana móvil, no un intervalo fijo:
- Cada vez que realizas una solicitud, el servidor cuenta cuántas de tus solicitudes se han recibido en los últimos 60 segundos.
- Si ese recuento ya es ≥ 60, la solicitud se rechaza con
429. - De lo contrario, el proceso continúa, se registra y contribuye a futuras ventanas.
Así que una ráfaga de 60 solicitudes a t = 0 se despeja a las t=60, no al comienzo del minuto siguiente. No hay Retry-After encabezado: espera aproximadamente 1 segundo y vuelve a intentarlo, o retrocede como se indica a continuación.
de retroceso#
Un bucle pragmático:
async function withRetry(fn, { maxAttempts = 6, baseMs = 1000 } = {}) {
for (let attempt = 1; ; attempt++) {
try {
return await fn();
} catch (err) {
const isRateLimited =
/Rate limit exceeded/.test(err.message);
const isUpstream5xx =
/Upstream error/.test(err.message);
if (!isRateLimited && !isUpstream5xx) throw err;
if (attempt >= maxAttempts) throw err;
const delay = baseMs * Math.pow(2, attempt - 1) + Math.random() * 250;
await new Promise((r) => setTimeout(r, delay));
}
}
}
Notas:
- Utiliza un retroceso exponencial con fluctuación. Un piso
setTimeout(1000)en cada nuevo intento entrará en conflicto consigo mismo si se ejecuta en paralelo. - No volver a intentarlo en
403,404,401, o el agotamiento del crédito429. Esos no se recuperarán en un minuto. - Intentos de tapón. Seis intentos con
baseMs=1000ya cubre aproximadamente 1 minuto de retardo; si sigues estando limitado por la tasa después de eso, significa que mantienes un ritmo superior a 60 por minuto y necesitas menos trabajadores simultáneos, no más reintentos.
Diseñar dentro de los
| Carga de trabajo | La concurrencia para garantizar la seguridad |
|---|---|
| Scripts rápidos / Rellenos puntuales | 1 trabajador, sin control de ritmo especial. Alcanzarás la cuota mucho antes de llegar al límite de velocidad. |
| ETL continuo | 1 proceso, espera aproximadamente 1 s entre solicitudes. Predecible, nunca se satura. |
| Crawlers con gran cantidad de ráfagas | Entre 2 y 4 trabajadores con un «token bucket» de 60/min en total para todos los trabajadores. Centralizar el «token bucket». |
| Paneles en tiempo real / consultas por usuario | Almacenamiento en caché en el borde; nunca servir más de 60 solicitudes por minuto por usuario desde el servidor de origen. |
El límite se aplica por usuario, no por dirección IP ni por clave; generar varias claves no lo aumenta.
Límite de solicitudes frente a
| Preocupación | Límite | Restablecer |
|---|---|---|
| Ráfaga | 60 / 60 en movimiento | Continuo |
| Volumen | 20 000 por mes natural | Primera solicitud con tarifa por uso del nuevo mes (servidor Y-m) |
En la práctica, las cargas de trabajo continuadas agotan la cuota de créditos mucho antes de alcanzar el límite de velocidad. El límite de velocidad existe principalmente para evitar bucles incontrolados.
Cómo determinar la causa de un 429#
Tanto el límite de tarifas por minuto como el límite de crédito mensual devuelven un 429 código de estado. Puedes distinguirlos examinando el cuerpo de la respuesta:
if (res.status === 429) {
const body = await res.json();
if (body && body.credits) {
// Monthly credit limit reached.
// Do not retry until next month or you upgrade your plan.
} else {
// Per-minute rate limit reached.
// Implement a backoff strategy and retry.
}
}
Consulte la sección «Errores » para ver la lista completa de códigos de estado.
comunes#
- Jornadas intensas sin dormir. A
parabucle sinesperarEl intervalo entre solicitudes agotará las 60 llamadas en milisegundos y provocará un bloqueo. - Paralelización sin un limitador compartido. Dos trabajadores que procesan 40 por minuto cada uno activarán el límite, aunque cada uno parezca «seguro».
- Volver a intentarlo
403/404como si fueran límites de velocidad. Eso significa «acceso denegado» o «ruta incorrecta»; no funcionarán a menos que se modifique la solicitud o la cuenta. - Encuesta
/créditospara detectar la velocidad limitante. Ese punto final cuenta para el límite de rate (y consume un crédito). Fíjate en el429en su lugar.