Rate limits
Leaky-bucket limits, response headers, and how to back off correctly.
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.
| Plan | Burst | Sustained |
|---|---|---|
| Enterprise | 40 requests | 2 requests/second |
| Enterprise+ | 80 requests | 4 requests/second |
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: 1784900412Reset 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.
Last updated on July 28, 2026
Need help?
The API is in private beta — email us and a human replies, usually within one business day.