429 response — your unit balance is not affected.
Limits by plan
Rate limits are enforced at the API key level. Concurrent request caps count the number of in-flight requests at any given moment — requests that have been sent but whose responses have not yet been received.
Rate limit errors
When you exceed either your requests-per-minute limit or your concurrency cap, Glade API returns an HTTP429 with a JSON error body:
429 responses are never billed. The failed request consumes zero units and does not affect your quota balance.
Handling 429s gracefully
The most reliable way to handle rate limit errors is to implement exponential backoff with jitter. This spreads retried requests over time and avoids a thundering herd when multiple requests hit the limit simultaneously.Concurrent request limits
Each plan caps the number of in-flight requests at once. If you fire more concurrent requests than your plan allows, the excess requests receive a429 immediately.
When processing large batches — for example, enriching a catalogue of thousands of ASINs — use a concurrency limiter in your code to stay within your plan’s cap. In Node.js, p-limit makes this straightforward:
pLimit value to your plan’s concurrent request cap:
Keeping your concurrency at or below the cap means every request is accepted on the first attempt, your throughput is maximised, and you avoid the latency cost of retrying
429 errors.
