Rate limiting

OrderFast limita la cantidad de requests que puede hacer cada credencial Bearer. El objetivo es proteger la plataforma y garantizar un uso justo entre integraciones.

Los límites se aplican por credencial, no por IP ni por endpoint individual.

Tipos de límite

Cada credencial puede tener dos límites configurados:

Límite	Ventana	Qué controla
Por minuto	60 segundos	Picos de tráfico en tiempo real
Mensual	Calendario mensual	Volumen total de requests del período

Si tu integración supera cualquiera de los dos, la API responde con 429 Too Many Requests.

Límites de tu credencial

Los valores exactos dependen de tu credencial y del plan asignado. Consultalos con el equipo de OrderFast o revisá los headers de respuesta en cada request.

Headers de respuesta

Toda respuesta exitosa incluye headers que te permiten monitorear el consumo en tiempo real:

X-RateLimit-Limit: 200
X-RateLimit-Remaining: 185
X-RateLimit-Reset: 1783420800

Header	Descripción
X-RateLimit-Limit	Máximo de requests permitidos en la ventana actual
X-RateLimit-Remaining	Requests que te quedan antes de alcanzar el límite
X-RateLimit-Reset	Timestamp Unix (segundos) en que se reinicia la ventana

Usá X-RateLimit-Remaining para frenar tu cliente antes de recibir un error, y X-RateLimit-Reset para calcular cuándo reintentar.

Qué hacer cuando recibís un 429

Si superás el límite, la API responde con:

{
  "error": {
    "code": "rate_limited",
    "message": "Too many requests. Please retry later.",
    "request_id": "req_01J..."
  }
}

Pasos recomendados:

1. No reintentar de inmediato — los reintentos agresivos empeoran la situación.
2. Esperar hasta X-RateLimit-Reset — convertí el timestamp a fecha y programá el próximo intento.
3. Usar backoff exponencial — si no tenés el header, empezá con 1 s y duplicá hasta un máximo razonable (por ejemplo, 60 s).
4. Registrar el request_id — útil si necesitás soporte.

Buenas prácticas

• Leé los headers en cada respuesta y adaptá la velocidad de tu cliente dinámicamente.
• Evitá polling agresivo — preferí webhooks para recibir eventos en lugar de consultar endpoints en loop.
• Agrupá operaciones cuando sea posible (por ejemplo, listados paginados en lugar de requests individuales por recurso).
• Cacheá respuestas que no cambian frecuentemente, como métodos de pago o configuración de location.
• Distribuí la carga si sincronizás catálogo al inicio — no dispares cientos de requests en paralelo.

Relacionado

• Errores — formato completo de errores, incluido rate_limited
• Autenticación — la validación de rate limit ocurre junto con permisos y estado de la credencial