"API de Amazon" señala al menos a tres cosas distintas que no se solapan. Elegir mal no te cuesta velocidad: te cuesta descubrir, a mitad de camino, que los datos que necesitabas nunca estuvieron en esa vía.
La línea divisoria es de quién son los datos
| SP-API oficial | API de datos de terceros | Scraping propio | |
|---|---|---|---|
| De quién | Solo de tu tienda | Datos públicos del marketplace | Lo que hay en la página |
| Campos típicos | Pedidos, inventario, liquidaciones, informes de publicidad | Competencia, palabras clave, mercados, rankings | Lo que las otras dos no cubren |
| Autorización | Concesión de la cuenta de vendedor | Clave de API | Ninguna |
| ¿Ve competidores? | No | Sí, como estimaciones | Sí, si lo mantienes |
La celda importante de esa tabla es el "No".
El error más común: SP-API para datos de la competencia
SP-API es la Selling Partner API. Atiende a los socios de venta y sus datos de negocio autorizados: tus pedidos, inventario, liquidaciones e informes publicitarios. Exacto, autorizado y al día.
No da nada sobre un competidor. Ni volumen de pedidos, ni tasa de conversión, ni gasto en publicidad. No es una cuestión de permisos: está fuera de alcance por diseño.
El error es fácil porque "API oficial" suena a que debería tenerlo todo. La separación real es: la API oficial da tus datos reales, los endpoints de terceros dan datos estimados de otros. Son complementarios, no alternativos.
Por eso esta combinación es el montaje habitual en la práctica:
Tu ACOS y tu volumen de pedidos desde SP-API (exacto), y bajo qué palabras clave posiciona un competidor desde un endpoint de terceros (estimado). Juntos responden si conviene subir la puja en esa palabra.
Ninguno de los dos lo responde por separado.
Qué cubre una API de datos de terceros
La mitad pública: productos, categorías, palabras clave, tráfico, rankings, reseñas.
Catálogo de API46 endpoints agrupados por productos, palabras clave, mercados, tráfico y marcas, con lo que devuelve cada unoTres cosas que conviene establecer antes de comprometerse con esta vía:
1. Qué cifras son estimaciones. Las ventas y los ingresos siempre lo son: el marketplace no los publica. El precio, el BSR y el número de valoraciones son hechos. Un endpoint que no los distinga te deja sin poder juzgar cuán firme es una conclusión.
2. Frescura y marcas de tiempo. Un dato sin marca de tiempo no sostiene una afirmación sobre tendencias. Necesitas saber cuándo se midió.
3. Cobertura de marketplaces. Que funcione en Estados Unidos no implica nada sobre el mercado en el que vendes. Verifícalo aparte.
Cuándo el scraping sigue teniendo sentido
Existen campos que las dos primeras vías no alcanzan: un módulo concreto de la página, una insignia que solo aparece en ciertas condiciones, una categoría tan nueva que ninguna fuente la cubre todavía.
Antes de tomar ese camino, calcula el coste con honestidad. Ponerlo en marcha es el primer día; después vienen las medidas antibot, los rediseños de página, los límites de cumplimiento y la marcha de quien lo mantiene. Lo más difícil de presupuestar es lo segundo: no puedes predecir cuándo cambiará el marcado ni si el cambio afectará justo a la estructura de la que dependes.
Una prueba sencilla: ¿este campo lo necesitas solo tú? Si es una necesidad común, seguramente ya hay un endpoint y estarías reinventando la rueda. Si de verdad solo importa a tu negocio, el scraping se justifica.
Esta entrada no trata de evadir la detección.
En qué orden decidir
Dos preguntas suelen bastar.
Primera: ¿quiero mis datos o los de otro?
- Los tuyos → SP-API, listo
- Los de otro → sigue
Segunda: ¿el campo es visible públicamente?
- Sí → endpoint de terceros, comprueba que esté en la cobertura
- No → puede que no sea obtenible en absoluto (abajo)
Tres cosas que ninguna de las tres vías devuelve
Merecen lista aparte, porque implican reformular el requisito en vez de cambiar de fuente.
El informe de términos de búsqueda del backend de un competidor. Datos autorizados de su cuenta de vendedor, visibles solo para ella.
El volumen real de pedidos de un competidor. No se publica. Toda cifra de ventas mensuales se deriva del BSR.
La identidad de los compradores. No está disponible, y es la dirección equivocada.
Si un plan depende de alguno de estos, lo que hay que cambiar es el plan, no la fuente de datos.
Lo que cuesta mantener cada vía
| SP-API | API de terceros | Scraping | |
|---|---|---|---|
| Tiempo hasta empezar | Solicitud y aprobación | Crear una clave | Según el objetivo |
| Coste inicial | Horas de desarrollo | Horas de desarrollo más llamadas | Horas de desarrollo |
| Coste continuo | Mantener la concesión | Coste por llamada | Antibot y seguimiento de rediseños |
| Lo menos predecible | Plazos de aprobación | Crecimiento de uso | Cambios de la plataforma |
El coste continuo de la columna de terceros es presupuestable por volumen de llamadas. El del scraping no. Esa es la diferencia más práctica entre ambas.
Si eliges la vía de terceros, La guía completa de las API de datos de Amazon desglosa los 46 endpoints por el trabajo de cada uno y cómo encadenarlos. Esta entrada resuelve la pregunta anterior: cuál de las tres vías tomar.
Preguntas
¿MWS sigue funcionando? MWS está retirado; la vía soportada es SP-API. Si mantienes una integración con MWS, migrar es obligatorio, no opcional.
¿Puede una sola API cubrirlo todo? No. La tabla de "de quién son los datos" es la razón: los datos propios y los ajenos vienen de modelos de autorización distintos, y ningún endpoint abarca ambos.
¿Son precisos los datos de terceros? Depende del campo. El precio, el BSR y el número de valoraciones son públicos y precisos. Las ventas y los ingresos son estimaciones cuya precisión depende del modelo y de la categoría. Pregunta por los dos grupos por separado.
¿Puedo validar primero con una opción gratuita? Sí, siempre que valides con carga de trabajo real y no con una demo. Los límites suelen aparecer solo tras una pasada completa del flujo.