Límites de uso

La API de Revi aplica protección de requests para mantener estables las integraciones.

Límites actuales

Contexto	Límite
Requests sin API key	60 requests por minuto por IP
Requests con API key	200 requests por minuto por API key

Estos valores reflejan los límites actuales de la API pública y pueden cambiar por entorno.

En /api/2026-10, los límites son 200 requests por minuto y credencial y 1.000 requests por minuto y negocio. Se aplican igual en todos los planes.

Estas versiones también protegen las operaciones que más trabajo generan en la base de datos:

Carga	Por credencial	Por negocio
Elementos escritos de pedidos, productos o supresiones	500 elementos/minuto	1.000 elementos/minuto
Estadísticas y búsquedas de productos	60 requests/minuto	240 requests/minuto

Cada request puede incluir como máximo 100 pedidos o productos, el body está limitado a 2 MiB y la paginación numerada admite páginas entre 1 y 1.000. Estos controles son iguales en todos los planes y no sustituyen los límites generales de requests. En escrituras de productos, cada idioma y combinación también cuenta como un elemento porque genera trabajo de persistencia independiente.

Headers de respuesta

Las requests correctas y fallidas pueden incluir:

X-RateLimit-Limit: 200
X-RateLimit-Remaining: 193
X-RateLimit-Business-Limit: 1000
X-RateLimit-Business-Remaining: 947

Cuando se supera el límite:

HTTP/1.1 429 Too Many Requests
Retry-After: 42
X-RateLimit-Limit: 200
X-RateLimit-Remaining: 0
X-RateLimit-Workload: expensive_reads
X-RateLimit-Workload-Limit: 60
X-RateLimit-Workload-Remaining: 0

{
  "success": false,
  "error": {
    "code": "rate_limited",
    "message": "Rate limit exceeded."
  },
  "meta": {
    "api_version": "2026-10",
    "retry_after": 42,
    "limited_bucket": "expensive_reads"
  }
}

Recomendaciones para clientes

• Usa backoff exponencial para fallos transitorios.
• Deja de enviar requests hasta que haya pasado Retry-After tras un 429.
• Agrupa pedidos y productos usando los endpoints batch documentados.
• Mantén cada lote en 100 elementos o menos y divide las importaciones iniciales grandes en varias requests.
• Evita sincronizar todo el histórico en cada cron.