Skip to main content
Para que una app no degrade la tienda de un comerciante, limitamos cuántas requests puede hacer. El límite se calcula por la combinación app × comercio: tu app tiene un cupo propio en cada tienda donde está instalada, y el uso en una tienda no afecta a las demás.

​
Cómo funciona

Usamos un cubo que se vacía de a poco (leaky bucket): cada request llena el cubo una unidad, y el cubo se vacía a un ritmo constante. Mientras no se desborde, podés hacer ráfagas. En la práctica, en una tienda Professional podés hacer una ráfaga de 40 requests y después sostener 2 por segundo.

​
Headers

Las respuestas a requests autenticados (incluidos los errores de la API) traen: Cuando te pasás, la respuesta es 429 rate_limited e incluye además Retry-After, con los segundos que tenés que esperar antes de reintentar:
Los endpoints de OAuth tienen sus propios límites (ver Autenticación OAuth).

​
Recomendaciones

  • Respetá Retry-After. Es el tiempo mínimo antes de que haya lugar de nuevo.
  • Reintentá con backoff exponencial (1 s, 2 s, 4 s…) y algo de variación aleatoria, para que varios workers no reintenten todos a la vez.
  • Mirá X-RateLimit-Remaining y frená antes de llegar a cero, en lugar de esperar al 429.
  • No hagas polling. Para enterarte de cambios, suscribite a webhooks y, para la sincronización de respaldo, pedí sólo lo nuevo con updated_since en lugar de recorrer todo el catálogo.
  • Paginá con limit alto (hasta 100) en vez de muchas páginas chicas.
El polling agresivo es causal de rechazo en la revisión de tu app (ver Revisión y publicación). En la homologación te pedimos un diagrama de secuencia de cómo consultás la API.