429
con cuánto esperar. Cacheá las recomendaciones por contexto y no gastes la cuota
dos veces en lo mismo.
Cómo se cuenta
- Se cuenta por clave, después de autenticar. Un pedido sin clave no gasta cuota de nadie.
- El presupuesto se rellena de a poco, no por ventana fija.
- Pasado el presupuesto, la respuesta es
429 rate_limitedconRetry-Afteren segundos.
Qué hacer con un 429
- Esperar lo que dice
Retry-After, no menos. - No reintentar en loop. El SDK no reintenta solo un pedido de
recomendaciones:
tryGetRecommendationsdevuelvenully la página sigue. Las señales sí se reintentan, con espera creciente. - Buscar el loop. Casi siempre es un render que se repite: un efecto sin dependencias, un observer que dispara varias veces, un pedido por tarjeta.
Qué cachear
Una recomendación vale lo que dura la vista. Cachearla ahorra cuota, y el comprador ve la misma lista al volver atrás.
No cachees una respuesta vacía porque el motor no contestó: puede volver en
segundos. Tampoco una recomendación más allá de la sesión:
decision_id (el id de la recomendación) ata las
señales, y una recomendación vieja atribuye mal.
Qué vas a ver
Un429 trae Retry-After y un request_id. Con eso y la pestaña Red
encontrás el pedido que se repite.
Si no lo ves
Claves y seguridad
Por qué la cuota es parte de la seguridad de la clave.
Errores
Cada error de la API, con su código y qué hacer.