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.

Partners: with the Nembol-Account header, each company has its own bucket, so one busy company never slows down the others. Its size comes from that company's plan, not yours. Calls without the header (your own store, /accounts, /partner/*) use the key's bucket, sized by your plan.

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 the headers to back off before hitting 429:

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

Remaining is how many requests fit right now. Reset is the Unix epoch second at which the bucket is completely full again (all Limit requests available), not the next free slot: right after a 429 it can be many seconds away while a single request already fits again. To know when the next request fits, use Retry-After on the 429.

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 rather than guessed). 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 used up. 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 October 21, 2026