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 cuentaRáfagaSostenido
Enterprise+80 peticiones4 peticiones/segundo
Prueba (claves de prueba, cualquier plan), y cualquier otro plan (p. ej. una empresa de partner en Pro)40 peticiones2 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: 1784900412

Remaining 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.

En esta página