Rate limits

Nembol uses a leaky bucket per API key (the same model as Shopify): you can burst up to the bucket size, and the bucket drains at a steady rate.

On top of the request limit there is a daily write quota on channel-mutating requests (product writes, inventory updates, publish/delist) — because every write consumes your own channels' API quotas too. Your current usage is visible in the dashboard under Settings → Developers → Usage.

Headers

Every response tells you where you stand — use them to back off before hitting 429:

X-RateLimit-Limit: 40
X-RateLimit-Remaining: 12
X-RateLimit-Reset: 1784900412

Reset is the Unix epoch second at which the bucket has capacity again.

When you hit 429

{ "error": { "type": "rate_limit_error", "code": "rate_limit_exceeded", "message": "…" } }

The response carries Retry-After (seconds, exact — computed from the bucket, not a guess). Sleep that long and retry. For sustained throughput, pace your requests at the sustained rate instead of bursting and sleeping.

write_quota_exceeded (also 429) means the daily write quota is done — it resets at midnight UTC; reads keep working.

Channel limits matter more than ours

Every product/inventory write eventually calls your channels' APIs, which have their own (often much tighter) limits. Nembol's workers respect them automatically — when a channel throttles, the operation reports channel_rate_limited and Nembol retries with backoff. Batch endpoints (POST /inventory/batch) are the efficient way to do bulk updates: one API request, optimally paced channel calls.