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_limitedwithRetry-Afterin seconds.
What to do with a 429
- Wait what
Retry-Aftersays, no less. - Don’t retry in a loop. The SDK doesn’t retry a recommendations request
on its own:
tryGetRecommendationsreturnsnulland the page goes on. Signals are retried, with growing backoff. - 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
A429 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.