Cada clave tiene 60 pedidos por minuto; pasado eso, la API responde 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_limited con Retry-After en segundos.

Qué hacer con un 429

  1. Esperar lo que dice Retry-After, no menos.
  2. No reintentar en loop. El SDK no reintenta solo un pedido de recomendaciones: tryGetRecommendations devuelve null y la página sigue. Las señales sí se reintentan, con espera creciente.
  3. 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

Un 429 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.