Traducida del inglés. Si hay alguna diferencia, la página en inglés es la referencia. Leer en inglés
Rate limits
Límites de tipo leaky bucket, headers de respuesta y cómo hacer backoff correctamente.
Nembol usa un leaky bucket por clave API (el mismo modelo que Shopify): puedes hacer ráfagas hasta el tamaño del bucket, y el bucket se vacía a un ritmo constante.
Partners: con el header Nembol-Account, cada empresa tiene su propio
bucket, así que una empresa con mucha actividad nunca ralentiza a las demás. Su tamaño depende
del plan de esa empresa, no del tuyo. Las llamadas sin el header (tu propia tienda,
/accounts, /partner/*) usan el bucket de la clave, dimensionado según tu plan.
| Plan de la cuenta | Ráfaga | Sostenido |
|---|---|---|
| Enterprise+ | 80 peticiones | 4 peticiones/segundo |
| Prueba (claves de prueba, cualquier plan), y cualquier otro plan (p. ej. una empresa de partner en Pro) | 40 peticiones | 2 peticiones/segundo |
Además del límite de peticiones hay una cuota diaria de escrituras en las peticiones que modifican los canales (escrituras de productos, actualizaciones de inventario, publicar/retirar), porque cada escritura también consume las cuotas de API de tus propios canales. Tu uso actual se ve en el panel, en Configuración → Desarrolladores → Uso.
Headers
Cada respuesta te dice en qué punto estás. Usa los headers para frenar antes de llegar al 429:
X-RateLimit-Limit: 40
X-RateLimit-Remaining: 12
X-RateLimit-Reset: 1784900412Remaining es cuántas peticiones caben ahora mismo. Reset es el segundo Unix epoch
en el que el bucket vuelve a estar completamente lleno (todas las peticiones de Limit
disponibles), no el siguiente hueco libre: justo después de un 429 puede faltar mucho
mientras una sola petición ya cabe de nuevo. Para saber cuándo cabe la siguiente
petición, usa Retry-After en el 429.
Cuando recibes un 429
{ "error": { "type": "rate_limit_error", "code": "rate_limit_exceeded", "message": "…" } }La respuesta incluye Retry-After (en segundos, exacto, calculado a partir del
bucket en lugar de estimado). Espera ese tiempo y reintenta. Para un rendimiento sostenido,
ajusta tus peticiones al ritmo sostenido en lugar de hacer ráfagas y esperar.
write_quota_exceeded (también 429) significa que se ha agotado la cuota diaria de escrituras.
Se reinicia a medianoche UTC; las lecturas siguen funcionando.
Los límites de los canales importan más que los nuestros
Cada escritura de producto/inventario acaba llamando a las API de tus canales, que
tienen sus propios límites (a menudo mucho más estrictos). Los workers de Nembol los respetan
automáticamente. Cuando un canal limita las peticiones, la operación indica
channel_rate_limited y Nembol reintenta con backoff. Los endpoints por lotes
(POST /inventory/batch) son la forma eficiente de hacer actualizaciones masivas: una sola
petición a la API, llamadas a los canales con el ritmo óptimo.
Última actualización el 21 de octubre de 2026
¿Necesitas ayuda?
Escríbenos y te responde una persona, normalmente en un día laborable.