Each key has 60 requests per minute; past that, the API returns 429 with how long to wait. Cache recommendations by context and don’t spend the quota twice on the same thing.

How it’s counted

  • It’s counted per key, after authentication. A request without a key spends nobody’s quota.
  • The budget refills gradually, not per fixed window.
  • Past the budget, the response is 429 rate_limited with Retry-After in seconds.

What to do with a 429

  1. Wait what Retry-After says, no less.
  2. Don’t retry in a loop. The SDK doesn’t retry a recommendations request on its own: tryGetRecommendations returns null and the page goes on. Signals are retried, with growing backoff.
  3. Find the loop. It’s almost always a render that repeats: an effect without dependencies, an observer that fires several times, a request per card.

What to cache

A recommendation is valid for as long as the view lasts. Caching it saves quota, and the shopper sees the same list when going back. Don’t cache an empty response because the engine didn’t answer: it can come back in seconds. Nor a recommendation beyond the session: decision_id (the recommendation’s id) ties the signals, and a stale recommendation misattributes.

What you will see

A 429 carries Retry-After and a request_id. With those and the Network tab you find the request that repeats.

If you don’t see it

Keys and security

Why the quota is part of the key’s security.

Errors

Every API error, with its code and what to do.