La parte técnica de integrar una API de datos es corta: crear una clave, enviar la petición que muestra la documentación y comprobar el código de estado. Primeros pasos y Autenticación ya lo cubren.
Lo caro son las cinco decisiones anteriores. Lo que tienen en común: cada una es barata de tomar ahora y dolorosa de cambiar cuando ya estás en marcha.
Decisión 1: cómo estimar el volumen de llamadas
Esta cifra elige tu paquete de llamadas y marca cuán ajustadas deben ser las otras cuatro decisiones.
El error más frecuente es contar un informe como una llamada. Un informe semanal de competencia suele ser 20 ASIN × 3 grupos de campos × una vez por semana = 60 llamadas; y si además traes doce meses de histórico para comparar, la primera pasada puede ser de varios cientos.
Estímalo como entidades × grupos de campos × frecuencia, y presupuesta el relleno inicial aparte, como un gasto puntual. La primera pasada y el régimen estable suelen diferir en un orden de magnitud, y estimar solo el régimen estable revienta el presupuesto el primer día.
Decisión 2: qué campos guardar y cuáles pedir en vivo
Lo decide una sola pregunta: ¿cada cuánto cambia este campo?
| Velocidad de cambio | Campos típicos | Qué hacer |
|---|---|---|
| Prácticamente fijo | ASIN, marca, categoría, fecha de alta | Guardarlo y pedirlo solo si falta |
| Diario | BSR, número de valoraciones, estimaciones de ventas | Guardarlo más un refresco programado |
| Continuo | Precio, cupones, disponibilidad | Pedirlo en vivo, nunca cachear de un día para otro |
Los dos extremos desperdician dinero. Si no guardas nada, pagas una y otra vez por datos que nunca cambiaron. Si lo guardas todo, decides sobre un precio caducado.
Diseñarlo como dos tablas — campos lentos en una, campos rápidos en un registro con marca de tiempo — es mucho más fácil que separarlos después. Un número sin marca de tiempo no se puede juzgar como vigente tres meses más tarde.
Decisión 3: los reintentos hay que clasificarlos, no unificarlos
Es lo que más veces se escribe mal. Los fallos no son una sola cosa, así que la lógica de reintento no debería ser una sola rama.
| Estado | Código de error típico | ¿Vale reintentar? | Qué hacer |
|---|---|---|---|
400 | VALIDATION_ERROR | No | Reintentar sin cambiar la petición vuelve a fallar |
401 | INVALID_API_KEY, API_KEY_EXPIRED | No | Sustituye la clave; no apliques espera y reintento |
402 | INSUFFICIENT_CREDITS | No | Sin saldo: ningún número de reintentos funciona |
403 | ENDPOINT_NOT_INCLUDED | No | El plan no incluye ese endpoint |
413 | — | No | Cuerpo de más de 64 KB; divide el lote |
429 | RATE_LIMIT_EXCEEDED, CONCURRENCY_LIMIT_EXCEEDED | Sí | Espera según Retry-After |
503, 504 | SERVICE_BUSY, SERVICE_TIMEOUT | Sí | Retroceso exponencial con jitter |
402 y 429 se parecen y no son el mismo problema. 429 significa "vas demasiado rápido ahora, espera", y esperar lo resuelve. 402 significa que se acabó el saldo; lo que necesita es una alerta y una recarga, no un bucle de reintentos. Si los metes en la misma rama catch, el día que se agoten los créditos tus tareas girarán en silencio sin producir nada.
Los dos códigos bajo 429 también difieren. RATE_LIMIT_EXCEEDED son demasiadas peticiones por minuto; CONCURRENCY_LIMIT_EXCEEDED son demasiadas en vuelo a la vez. El primero se arregla bajando el ritmo y el segundo bajando el paralelismo — y bajar el ritmo no baja el paralelismo.
Para esto existen tres cabeceras de respuesta:
| Cabecera | Significado |
|---|---|
X-RateLimit-Limit | Peticiones permitidas en la ventana de un minuto |
X-RateLimit-Remaining | Peticiones restantes en la ventana actual |
X-RateLimit-Reset | Momento de reinicio de la ventana, en segundos Unix |
No esperes al 429. Reduce el ritmo cuando X-RateLimit-Remaining baje de un umbral y obtendrás más rendimiento que esperando después de que te limiten.
Sobre si una petición fallida consume créditos: no lo supongas. Con la sesión iniciada puedes ver los metadatos de las peticiones en la página de uso, donde los cuerpos y respuestas anonimizados se conservan siete días. Provoca un fallo a propósito antes de lanzar y contrástalo con el detalle de llamadas, que es más fiable que cualquier suposición.
Errores y límites de frecuenciaTabla completa de códigos de estado, lista de códigos de error, cabeceras de límite y cuánto se conserva el detalle de llamadasDecisión 4: la concurrencia es un presupuesto de cuenta, no un ajuste por tarea
Es la regla menos intuitiva y la que muerde al escalar:
RPM, concurrencia y créditos se agregan por cuenta. Crear más claves API no concede cupo adicional.
El instinto es dar a cada tarea su propia clave para que corran independientes. No lo hacen. Tres tareas programadas que abren diez conexiones cada una ponen treinta en vuelo contra un único techo de cuenta, y la que arranque primero empuja a las demás a CONCURRENCY_LIMIT_EXCEEDED.
Así que la concurrencia debe diseñarse como un único limitador compartido, no por tarea:
- Haz pasar todas las llamadas por un mismo envoltorio de cliente, con el limitador dentro del envoltorio y no en el código de negocio
- Da prioridades a las tareas: una consulta en vivo va por delante de un relleno nocturno
- Limita explícitamente el ritmo de los rellenos; no tienen prisa, y son los que más fácilmente se comen todo el cupo
Otro techo que conviene conocer de antemano: un cuerpo de petición de más de 64 KB devuelve 413. Cuando un endpoint por lotes recibe una lista de ASIN, ese límite fija el tamaño máximo del lote, y su sitio es la lógica de troceado, no una incidencia en producción.
Decisión 5: cómo gestionar las claves en un equipo
Dado que el cupo ya es compartido a nivel de cuenta, las claves adicionales no van de cupo. Su valor real son otras dos cosas: atribución y revocación independiente.
Repártelas por finalidad, no por persona:
- Sepáralas como
prod-api,cron-backfill,dev-localy el detalle de llamadas te dirá qué vía se portó mal - Cuando una vía falle, desactiva esa clave y el resto sigue funcionando
- Cuando alguien se va, la pregunta es qué claves tocó, no si rotar la cuenta entera
Tres líneas rojas: las claves viven solo en variables de entorno del servidor, nunca en el repositorio, nunca en el código de front-end. Todo lo que necesite datos en un navegador debería pasar por tu propio backend.
Qué comparten las cinco
Ninguna es un problema técnico difícil. Cada una es una elección cuyo coste de revertir es asimétrico. Si subestimas el volumen, lo descubres el primer mes. Si eliges mal el reparto de caché, lo descubres cuando los números dejan de cuadrar. Si escribes una sola rama de reintento, lo descubres el día que se agotan los créditos. Si fijas la concurrencia por tarea, lo descubres al lanzar la tercera. Si repartes claves por persona, lo descubres en la primera baja.
Media hora con estas cinco antes de la primera petición sale más barato que volver a por ellas después.
Cuando pases a elegir endpoints, La guía completa de las API de datos de Amazon desglosa los 46 endpoints por el trabajo de cada uno. Si todavía estás decidiendo si la vía de terceros es la correcta, empieza por Cómo elegir una API de datos de Amazon.
Preguntas
¿Más claves API suben mis límites? No. RPM, concurrencia y créditos se agregan por cuenta. Varias claves compran atribución y revocación independiente, no cupo.
¿Cuánto debo esperar tras un 429?
Sigue Retry-After cuando esté presente. Si no lo está, usa retroceso exponencial con jitter aleatorio para que varias tareas no reintenten a la vez.
¿Cómo confirmo si las peticiones fallidas consumen créditos? Mira el detalle de llamadas en la página de uso. Los metadatos anonimizados se conservan siete días, así que provoca un fallo antes de lanzar y léelo después.
¿Cuántos elementos caben en una petición por lotes? No hay una cifra única: lo acota el límite de 64 KB del cuerpo. Mídelo una vez con tus tamaños reales de parámetros y deja margen en la lógica de troceado.