Tiendanube · Rate Limits

Tiendanube Rate Limits

Tiendanube (Nuvemshop) enforces rate limits per app+store combination using a leaky-bucket algorithm. Each app has a bucket per store that holds a fixed number of request tokens and refills (leaks) at a steady rate. Every API call consumes one token; when the bucket is empty, requests are rejected with HTTP 429 until the bucket refills. The current fill state is surfaced on every response through rate-limit headers so clients can pace themselves. Exact bucket size and leak rate are set by the platform and may differ by app and plan; specific numeric values are not reconciled in this artifact.

Tiendanube Rate Limits is the machine-readable rate-limit profile for Tiendanube on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring requests and requests_per_second.

The profile also includes 2 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include E-commerce, Retail, Latin America, Storefront, and Rate Limiting.

3 Limits Throttle: 429
E-commerceRetailLatin AmericaStorefrontRate LimitingQuotasThrottling

Limits

Leaky Bucket Capacity app-store
requests
see provider documentation
Maximum number of request tokens a single app can hold for a single store at once (burst capacity).
Leak / Refill Rate app-store
requests_per_second
see provider documentation
Steady rate at which the bucket refills; sets the sustained requests-per-second ceiling per app+store.
Per-App Per-Store Scope app-store
requests
independent per store
Each installed store has its own bucket, so limits do not aggregate across a partner's installed base.

Policies

Leaky Bucket
Requests draw from a per-app-per-store token bucket that refills at a fixed leak rate; empty bucket returns HTTP 429.
Backoff Strategy
Clients should read the rate-limit response headers, throttle to the leak rate, and apply exponential backoff with jitter on 429.

Sources