Guía de la API de Keepa para datos de productos e historial de precios de Amazon

Escrito por Evan Huang

Publicado el 20 de agosto de 2026 • 18 min de lectura

La API de Keepa da a desarrolladores y vendedores de Amazon acceso programático a registros de productos, historial de precios, historial de clasificación de ventas, ofertas del mercado, promociones, información de vendedores y notificaciones de seguimiento. Resulta útil cuando un proceso de investigación supera las comprobaciones manuales de gráficos y necesita datos repetibles para muchos ASIN.

La parte difícil no suele ser enviar la primera solicitud. Es entender qué endpoint encaja con la tarea, cómo afecta el sistema de tokens de Keepa al rendimiento, cómo deben decodificarse sus matrices históricas compactas y qué campos pueden faltar o estar obsoletos. Una canalización que ignore esos detalles puede convertir datos válidos en conclusiones engañosas.

Esta guía explica la API de Keepa desde una perspectiva práctica. Cubre objetos principales de datos, costes en tokens, endpoints fundamentales, una solicitud básica de producto, casos de uso para vendedores y limitaciones importantes en producción. También explica cuándo puede ser útil una capa más amplia de datos de comercio electrónico después de que Keepa haya respondido las preguntas históricas de productos que mejor resuelve.

¿Qué es la API de Keepa?

Keepa es conocido por añadir gráficos históricos de precios a páginas de productos de Amazon. Su API expone gran parte del historial subyacente de productos y mercados de Amazon como JSON. La URL base es https://api.keepa.com/ y cada solicitud requiere una clave de acceso a la API.

La API está diseñada en torno a las regiones de Amazon. Una solicitud normalmente incluye un identificador de dominio, como domain=1 para Amazon.com, además de un ASIN, ID de vendedor, ID de categoría u objeto de consulta según el endpoint. Los datos de productos se devuelven mediante HTTPS y Keepa recomienda aceptar compresión gzip y reutilizar conexiones para integraciones eficientes.

La API sirve para varias tareas distintas:

• Recuperar un producto conocido mediante ASIN
• Buscar productos por palabra clave
• Filtrar la base de datos de productos mediante Product Finder
• Inspeccionar historiales de precio, clasificación de ventas, número de ofertas, valoración y reseñas
• Encontrar promociones recientes y cambios de valor
• Consultar vendedores, categorías y listas de superventas
• Crear reglas de seguimiento de productos y recibir notificaciones

Estas tareas no deben tratarse como una solicitud intercambiable. Consulta de productos, descubrimiento, actualización de ofertas y búsqueda de promociones tienen cargas y costes en tokens diferentes. Un flujo claro empieza por la pregunta empresarial y selecciona después el endpoint más limitado que pueda responderla.

¿Qué datos devuelve la API de Keepa?

El objeto de producto es el centro de la mayoría de los flujos de la API de Keepa. Combina metadatos con matrices históricas y objetos opcionales. Los campos disponibles dependen del tipo de producto, parámetros de solicitud, región y de si Keepa ha recopilado los datos.

Productos e historial de precios

Los campos habituales incluyen ASIN, título, marca, información de categoría, imágenes, relaciones de producto principal y variantes, dimensiones, peso del paquete, características, fechas del anuncio y marcas temporales de actualización. Las señales históricas se almacenan principalmente en la matriz bidimensional csv.

Cada índice de primer nivel de csv representa un tipo definido de historial. Entre los ejemplos importantes están:

Las entradas históricas suelen alternar una marca temporal de Keepa y un valor. Los historiales que incluyen envío usan entradas de tres partes: marca temporal, precio y envío. Los precios son enteros en la unidad mínima de moneda de la región. Un valor -1 suele significar que no había oferta disponible en ese intervalo.

Keepa añade una entrada histórica cuando cambia el valor, no cada vez que comprueba un producto. La serie temporal resultante se basa en eventos, no en una tabla diaria con intervalos regulares. El código analítico debe conservar esa distinción.

Señales de ventas y reseñas

El objeto de producto puede incluir historiales de clasificación de ventas principales y específicos de categoría. También puede incluir monthlySold, que representa el tramo visible de compras en el último mes de Amazon cuando está disponible. Keepa documenta ese valor como un tramo publicado por Amazon, no una estimación exacta de ventas, y la mayoría de ASIN puede no tenerlo.

Los historiales de reseñas y valoraciones también requieren interpretación cuidadosa. Algunos campos de reseñas dependen de parámetros, algunos no pueden actualizarse forzosamente y la disponibilidad de datos de Amazon ha cambiado con el tiempo. El historial ausente debe seguir ausente en el sistema posterior en lugar de convertirse en cero.

Ofertas y datos de vendedores

Usar el parámetro opcional offers puede devolver objetos de ofertas con identidad del vendedor, condición, indicadores Prime y FBA, precio, envío, existencias, cupones e historial de ofertas. También aumenta el consumo de tokens porque Keepa puede recuperar páginas de ofertas además del producto base.

Los datos de ofertas tienen un límite importante de actualidad. Amazon puede mostrar muchas ofertas, su orden cambia con frecuencia y Keepa no puede actualizar continuamente cada oferta de cada producto. La respuesta puede contener ofertas antiguas. Campos como offersSuccessful, liveOffersOrder y las marcas de actualización deben evaluarse antes de etiquetar una oferta como actual.

Promociones y seguimiento

El endpoint Deals identifica productos cuyo precio o clasificación de ventas cambió recientemente y coinciden con un filtro. Keepa afirma que los resultados se limitan a productos actualizados en las 12 horas anteriores. Una solicitud devuelve hasta 150 promociones, con paginación para conjuntos mayores.

La API Tracking tiene otra finalidad. Crea y gestiona reglas de seguimiento de productos y puede producir notificaciones cuando se cumplen condiciones. Esto es útil para alertas de precios y sistemas de supervisión, mientras el endpoint Deals sirve mejor para descubrir cambios recientes en un mercado filtrado.

¿Cómo funcionan los precios de la API de Keepa?

Los precios de la API de Keepa se vinculan a un cubo de tokens, no a un simple número mensual de solicitudes. Cada plan genera una cantidad fija de tokens por minuto. Las solicitudes consumen tokens y los no usados caducan después de 60 minutos.

Los precios exactos de suscripción deben comprobarse en la página de cuenta de la API de Keepa antes de presupuestar porque los importes pueden cambiar. La unidad duradera de planificación es la tasa de reposición del plan y el coste de tokens de los endpoints necesarios.

Costes de solicitudes de productos

La documentación oficial enumera estos ejemplos básicos:

Algunas opciones de endpoints tienen costes distintos. Las estimaciones de producción deben usar la página del endpoint pertinente en lugar de suponer que cada llamada cuesta un token.

Límites de reposición y ráfagas

Supón que un plan genera 60 tokens por minuto. Como los no usados caducan tras 60 minutos, su capacidad máxima de cubo es de 3,600 tokens. Eso permite una ráfaga hasta el saldo actual, seguida de nuevos tokens a la tasa de reposición.

Un gran total teórico mensual de tokens no significa que todo pueda gastarse en un lote. Las cargas también deben ajustarse a la tasa de reposición y capacidad del cubo. Una tarea nocturna que solicite cientos de miles de páginas caras de ofertas puede necesitar limitación de velocidad aunque sus cálculos mensuales parezcan aceptables.

Cada respuesta incluye campos como tokensLeft, tokensConsumed, refillRate y refillIn. Las aplicaciones deben registrarlos y pausar o encolar trabajo cuando el saldo se acerque al coste de la siguiente solicitud.

Planificación de la carga de trabajo

Una estimación realista separa las solicitudes económicas de productos del trabajo opcional de actualización:

monthly token demand =
  product ASIN requests
  + product search pages × 10
  + retrieved offer pages × 6
  + deal pages × 5
  + seller lookups
  + other endpoint costs

El cálculo debe usar los resultados esperados, no solo las llamadas enviadas. Por ejemplo, una solicitud de ofertas puede costar más si se encuentran más páginas. Probar una muestra representativa de ASIN da una estimación mejor que aplicar el coste mínimo a cada producto.

Elegir los endpoints adecuados de la API de Keepa

Keepa proporciona endpoints especializados en lugar de una operación universal de búsqueda. El siguiente mapa abarca los puntos de partida más habituales.

Solicitud de producto

/product recupera productos conocidos mediante ASIN o código de producto. Puede devolver metadatos e historial de precios, con estadísticas, ofertas, existencias, valoraciones, datos de Buy Box y parámetros históricos opcionales.

Úsalo cuando el flujo ya conozca qué ASIN analizar. Este endpoint es la elección habitual para seguimiento de competidores, comprobaciones del historial de precios y enriquecimiento de catálogos.

Product Search y Finder

/search?type=product busca productos de Amazon por palabra clave y devuelve objetos de producto. Es útil para una consulta directa de palabra clave a producto.

/query impulsa Product Finder y acepta una selección JSON más detallada. Sirve mejor para filtrar una base amplia de productos según condiciones como categoría, precio, clasificación de ventas, valoraciones, ofertas y cambios históricos. Los desarrolladores deben inspeccionar el esquema actual de Product Finder porque los filtros disponibles pueden ampliarse o cambiar.

Los equipos que comparen varios proveedores de datos de Amazon pueden usar una comparación más amplia de APIs de productos de Amazon para distinguir APIs históricas de APIs oficiales de vendedores, APIs de catálogos de afiliados y servicios de extracción en tiempo real.

Promociones, vendedores y categorías

/deal consulta cambios recientes de productos que coinciden con una consulta. /seller recupera información de vendedores. /category y la búsqueda de categorías resuelven objetos de categoría, mientras /bestsellers devuelve listas ordenadas de ASIN.

Estos endpoints respaldan seguimiento y descubrimiento de mercado, pero responden a preguntas distintas. Una consulta de promociones encuentra cambios recientes. Una solicitud de vendedor perfila un vendedor conocido del mercado. Una solicitud de superventas devuelve una lista ordenada de categoría. Combinarlos sin conservar fuente y marca temporal puede producir comparaciones engañosas.

Seguimiento y notificaciones

/tracking crea, actualiza y elimina reglas de seguimiento de productos. Los objetos de seguimiento definen producto, umbral, tipo de precio, canales de notificación y otras condiciones admitidas por la API.

El seguimiento es apropiado cuando la salida requerida es un evento, como alcanzar un precio objetivo. Las solicitudes periódicas de productos son más adecuadas cuando una aplicación necesita un registro histórico completo o una instantánea analítica personalizada.

Cómo realizar una solicitud a la API de Keepa

Una solicitud mínima de producto de Keepa necesita una clave de acceso, región de Amazon y ASIN. El ejemplo siguiente solicita un producto de Amazon.com:

curl -s --compressed \
  "https://api.keepa.com/product?key=YOUR_API_KEY&domain=1&asin=B00M0QVG3W"

Configuración de solicitudes

La clave API debe inyectarse desde un gestor de secretos o una variable de entorno. Nunca debe guardarse en un repositorio, escribirse en una aplicación de cliente ni colocarse en registros analíticos.

Para lotes mayores, la integración también debe definir:

• La región y el ID de dominio
• Máximo de ASIN por lote
• Parámetros opcionales necesarios
• Coste esperado en tokens
• Tiempo límite de solicitud y política de reintentos
• Duración de caché por tipo de datos
• Comportamiento de valores ausentes

Los parámetros opcionales deben activarse solo cuando el flujo necesite los datos adicionales. Añadir ofertas, existencias, valoración u otro trabajo de actualización aumenta tamaño de respuesta, tiempo de procesamiento y, a veces, coste en tokens.

Gestión de respuestas

Una respuesta satisfactoria contiene el estado actual de tokens y una matriz products. La integración debe validar el estado de respuesta, confirmar que se devolvió el ASIN solicitado, inspeccionar productType y decodificar después solo los campos necesarios para el caso de uso.

const url = new URL("https://api.keepa.com/product");
url.search = new URLSearchParams({
  key: process.env.KEEPA_API_KEY,
  domain: "1",
  asin: "B00M0QVG3W"
});

const response = await fetch(url, {
  headers: { "Accept-Encoding": "gzip" }
});

if (!response.ok) {
  throw new Error(`Keepa request failed: ${response.status}`);
}

const data = await response.json();
const product = data.products?.[0];

if (!product) {
  throw new Error("No product returned for the requested ASIN");
}

console.log({
  asin: product.asin,
  title: product.title,
  tokensLeft: data.tokensLeft,
  lastUpdate: product.lastUpdate
});

Las matrices históricas csv necesitan un decodificador separado. Las marcas temporales de Keepa usan minutos desde una época personalizada. Conviértelas a milisegundos Unix con (keepaTime + 21564000) * 60000. Conserva el tipo de historial porque algunas matrices contienen pares de marca temporal y valor, mientras los tipos con envío contienen tripletes de marca temporal, precio y envío.

Si la aplicación necesita resultados actuales de búsqueda de Amazon en lugar del historial de un ASIN conocido, un flujo de API de búsqueda de Amazon encaja mejor que consultar repetidamente el historial de productos.

Casos de uso de la API de Keepa para vendedores

Los datos históricos resultan útiles cuando están vinculados a una decisión. Los flujos siguientes son puntos de partida habituales para vendedores de Amazon, agencias y equipos de software de comercio electrónico.

Validación de precios y BSR

Un único precio actual puede ocultar ciclos de descuentos, agotamientos, picos estacionales y competencia inestable. El historial muestra si la oferta de hoy es normal, inusualmente baja o elevada. El historial de clasificación de ventas añade una señal de demanda, aunque BSR no debe tratarse como ventas unitarias exactas.

Un registro útil de validación puede incluir:

• Precios actuales de Amazon, nuevos, de segunda mano y de Buy Box
• Estadísticas de precios de 30 días y 90 días
• Historial de BSR de categoría principal y subcategorías
• Historial del número de ofertas nuevas y FBA
• Últimas horas de actualización de producto, precio y ofertas
• Indicadores de valores ausentes

El resultado respalda el filtrado de productos, pero no demuestra rentabilidad futura. Comisiones, conversión, demanda, estacionalidad y costes de abastecimiento siguen necesitando evidencia separada.

Seguimiento de competidores

Supervisar un conjunto fijo de ASIN puede revelar movimientos de precio, cambios de Buy Box, crecimiento de ofertas, variación de valoraciones y cambios de clasificación de ventas. La canalización más fiable almacena la hora de cada solicitud, la actualización de origen y la versión de decodificación junto a las observaciones.

Las alertas deben usar condiciones explícitas. Por ejemplo, un competidor que baje de un precio mínimo, un número de ofertas que supere un umbral o un BSR que salga de un intervalo definido. Etiquetas amplias como «el competidor está ganando» requieren más evidencia que un cambio de precio o posición.

Descubrimiento de productos

Product Search, Product Finder, Deals y Best Sellers pueden construir listas de candidatos. La siguiente fase debe enriquecer esos ASIN con estabilidad de precios, historial de posiciones, competencia de vendedores, valoraciones y contexto de categoría.

Esto es distinto de buscar un producto conocido. Los flujos de descubrimiento suelen consumir más tokens porque generan primero páginas de resultados y después solicitan detalles de los ASIN devueltos. Filtrar pronto reduce coste y datos irrelevantes.

Para equipos que desarrollen un proceso más amplio de abastecimiento, los métodos de investigación de productos deben combinar historial de mercado con demanda, competencia, comisiones, carencias en reseñas y restricciones de suministro.

Comprobaciones de promociones y disponibilidad

Deals puede revelar productos con cambios recientes de precio o posición. Las solicitudes de productos y ofertas pueden verificar después valores actuales, condiciones disponibles, información de vendedores y marcas de actualización.

La segunda verificación importa porque un registro de promoción refleja un cambio reciente, no garantiza que la misma oferta siga disponible. Un flujo robusto trata el resultado de promoción como candidato y confirma las entradas actuales de decisión antes de actuar.

Límites y calidad de datos de la API de Keepa

Keepa ofrece una cobertura histórica valiosa, pero toda API histórica tiene límites. Esos límites deben formar parte del modelo de datos, no quedar enterrados en la gestión de errores.

Actualidad y muestreo

Los campos de productos tienen marcas de actualización separadas. Precio, valoración, existencias, ofertas e información de vendedores pueden no compartir la misma actualidad. Una respuesta recibida ahora puede contener valores recopilados en momentos distintos.

El historial de ofertas merece cautela adicional. Keepa afirma que no es viable recuperar y actualizar continuamente miles de millones de ofertas. El parámetro offers controla cuántas páginas se recuperan y las ofertas antiguas pueden permanecer en el historial. Los flujos que requieran el estado actual de la página deben verificar la actualidad y considerar si una fuente de datos de Amazon en vivo encaja mejor.

Esta es también la principal diferencia entre una API de datos estructurados y una API de extracción. Una comparación de APIs de extracción de Amazon puede ayudar a evaluar actualidad, riesgo de análisis, variación por ubicación y responsabilidad de mantenimiento.

Valores ausentes

Los campos pueden ser null, indefinidos, vacíos, 0, -1 o no disponibles según la definición del campo. Esos estados no son intercambiables.

• -1 puede significar que no había oferta disponible en un intervalo del historial de precios.
• null puede significar que no se recopiló un tipo de historial.
• Un valor ausente de ventas mensuales no debe convertirse en cero ventas.
• Una posición ausente puede deberse al tipo de producto, comportamiento de categoría o datos no disponibles.
• Una lista incompleta de ofertas no debe presentarse como el mercado completo de vendedores.

Conserva los estados originales de ausencia antes de crear valores analíticos predeterminados. Una capa de visualización puede mostrar una raya o «no disponible», mientras el registro almacenado debe conservar el estado original y la marca temporal de origen.

Normalización de datos

Las respuestas de Keepa usan unidades mínimas de moneda por región, Keepa Time, matrices históricas indexadas y campos cuya disponibilidad depende de parámetros. Una capa de normalización debe convertirlos de forma coherente y conservar la carga original para depurar.

Los campos normalizados recomendados incluyen:

• source
• source_timestamp
• retrieved_at
• marketplace
• asin
• metric_name
• metric_value
• currency
• availability_state
• request_parameters
• schema_version

Keepa puede añadir tipos de historial a la matriz csv. El código debe basarse en constantes documentadas y tolerar índices adicionales en lugar de suponer que la matriz siempre tendrá una longitud fija.

Cuándo ayudan datos más amplios de Amazon

Keepa puede responder preguntas históricas profundas sobre productos, precios, posiciones, ofertas, vendedores y promociones de Amazon. Una investigación más amplia suele introducir preguntas adicionales: ¿qué palabras clave impulsan la demanda? ¿Qué quejas se repiten en las reseñas? ¿Qué ASIN competidores ocupan el mismo nicho? ¿Qué concentración tiene el mercado? ¿Qué estimaciones de ventas y señales de oportunidad respaldan la decisión de producto?

Gestionar esas preguntas con proveedores separados puede crear múltiples credenciales, esquemas, modelos de facturación y sistemas de reintentos. Una capa unificada de datos resulta útil cuando el flujo necesita historial procedente de Keepa junto a otra inteligencia de productos, palabras clave, reseñas, competidores, ventas y mercados.

Nexscope proporciona datos compatibles de comercio electrónico mediante API REST y MCP. Sus APIs documentadas Amazon Product History y Product Price Series cubren campos como tendencias de precios, tendencias BSR, número de vendedores, valoraciones, número de valoraciones y ventas mensuales cuando están disponibles. Otras APIs compatibles cubren descubrimiento de productos, demanda de palabras clave, reseñas, consulta de competidores, estimaciones de ventas e investigación de mercado.

El beneficio práctico es la consolidación operativa. Las llamadas compatibles usan una cuenta Nexscope y un saldo compartido de créditos en lugar de necesitar un contrato de integración independiente por fase. La disponibilidad del proveedor, campos de solicitud y respuesta, actualidad y coste de créditos siguen debiendo comprobarse por API. El acceso seleccionado procedente de Keepa no implica paridad completa con todos sus endpoints.

Este enfoque encaja con equipos que necesitan varias categorías de datos en un flujo REST o MCP. El acceso directo a Keepa sigue siendo adecuado cuando un producto requiere su conjunto completo de endpoints, su modelo nativo de seguimiento o un plan dedicado de tokens.

Añade más señales de Amazon a un flujo

Conecta datos compatibles de historial de productos, precios, BSR, vendedores, palabras clave, reseñas, competidores, ventas y mercados mediante una capa de datos de Amazon con API REST o MCP.

Explora la API de datos de Amazon →

Conclusión: construir un flujo fiable con la API de Keepa

La API de Keepa es una base sólida para productos e historial de precios de Amazon. Su objeto de producto puede respaldar análisis de precios, investigación BSR, seguimiento de ofertas, descubrimiento de promociones, consulta de vendedores y alertas. La calidad del resultado depende de elegir el endpoint correcto, presupuestar tokens con precisión, decodificar correctamente matrices históricas y conservar los límites de actualidad y valores ausentes.

Empieza con la solicitud más limitada que responda a la pregunta empresarial. Prueba el consumo de tokens con ASIN representativos, registra los campos de tokens devueltos por cada respuesta y almacena las marcas temporales de origen con los valores normalizados. Añade ofertas opcionales, existencias, valoraciones y actualizaciones en vivo solo cuando la decisión las necesite.

Cuando el flujo se amplíe a demanda de palabras clave, análisis de reseñas, descubrimiento de competidores, estimaciones de ventas u oportunidad de mercado, una capa más amplia puede reducir costes de integración. El acceso directo a Keepa sigue siendo adecuado para equipos que necesiten todo su alcance nativo.

Para equipos que necesitan más que datos históricos de productos, Nexscope reúne inteligencia compatible de historial de productos, precios, BSR, vendedores, palabras clave, reseñas, competidores, ventas y mercados en una cuenta con saldo compartido de créditos. El acceso mediante API REST y MCP facilita añadir estas señales a un conjunto de herramientas existente sin mantener integración y facturación separadas por cada fuente.

Preguntas frecuentes

¿Qué es la API de Keepa?

La API de Keepa es una interfaz medida por tokens para recuperar programáticamente datos del mercado de Amazon de Keepa. Proporciona metadatos de productos, historial de precios, historial de clasificación de ventas, ofertas del mercado, promociones, listas de superventas, información de vendedores, datos de categorías y notificaciones de seguimiento. Las solicitudes usan una clave API y devuelven JSON. El endpoint correcto depende de si el flujo parte de un ASIN conocido, palabra clave, consulta de filtros de producto, vendedor, categoría o condición de seguimiento.

¿Es gratuita la API de Keepa?

Keepa requiere un plan de API para obtener una clave de acceso. Los planes generan tokens a una tasa definida y las solicitudes los consumen. El precio exacto debe comprobarse en la página de cuenta de API de Keepa porque los importes pueden cambiar. La extensión de navegador y la API son productos diferentes, así que el acceso a gráficos de Keepa no proporciona automáticamente capacidad de API para una integración.

¿Cómo funcionan los precios de la API de Keepa?

Los precios combinan un plan de suscripción con un cubo de tokens. El plan genera una cantidad fija por minuto, los tokens no usados caducan tras 60 minutos y cada solicitud consume una cantidad documentada. Las solicitudes de producto empiezan en un token por ASIN, mientras búsquedas, páginas de ofertas, promociones y listas de superventas tienen costes distintos. La planificación debe contemplar tanto demanda mensual como tasa de reposición.

¿Qué datos devuelve la API de Keepa?

Los datos disponibles incluyen identidad del producto, títulos, marcas, categorías, imágenes, atributos, variantes, historiales de precios y clasificación de ventas, números de ofertas, valoraciones y reseñas, tramos de ventas mensuales, ofertas del mercado, información de vendedores, promociones y marcas de actualización. Algunos campos requieren parámetros opcionales y otros no están disponibles para determinados tipos o ASIN. Las aplicaciones deben validar productType, marcas temporales por campo y significados de valores ausentes antes de analizar.

¿Cómo se decodifica el historial de precios de Keepa?

La mayoría de historiales se almacena en la matriz csv del objeto de producto. Cada índice de primer nivel representa un tipo, como precio de Amazon, nuevo, usado, clasificación de ventas o precio de Buy Box. Las entradas alternan Keepa Time y un valor; los tipos con envío usan tripletes de marca temporal, precio y envío. Los precios usan la unidad mínima de moneda del mercado y -1 suele indicar que no había oferta disponible.

¿Pueden los datos de la API de Keepa estimar ventas de Amazon?

Keepa proporciona historial de clasificación de ventas y puede exponer el tramo de compras en el último mes de Amazon mediante monthlySold. La clasificación de ventas es una señal direccional del mercado, no una medida exacta de ventas unitarias. Keepa documenta monthlySold como un tramo publicado por Amazon, no una estimación, y no está disponible para muchos ASIN. Las estimaciones exactas de ventas requieren un método separado con supuestos e incertidumbre claramente indicados.

¿Hay una alternativa a la API de Keepa para datos más amplios de Amazon?

La mejor opción depende de los datos necesarios. El acceso directo a Keepa encaja con un historial profundo de productos, precios, posiciones, ofertas, vendedores, promociones y seguimiento de Amazon. Los equipos que también necesitan demanda de palabras clave, texto de reseñas, descubrimiento de competidores, estimaciones de ventas e investigación de mercado pueden preferir una capa más amplia. Nexscope proporciona datos compatibles de comercio electrónico mediante API REST y MCP con un saldo compartido de créditos y documenta límites de fuente y disponibilidad por endpoint.

¿Deben los desarrolladores usar Keepa o Amazon SP-API?

Tienen alcances diferentes. Keepa proporciona inteligencia de mercado e historial de productos para muchos ASIN. La Selling Partner API de Amazon proporciona a vendedores y proveedores autorizados datos operativos y acciones vinculados a sus propias cuentas, sujetos a roles y permisos de Amazon. Una aplicación de vendedor puede usar ambas: SP-API para operaciones de cuenta y Keepa para historial externo de productos y mercados, siempre que cada uso cumpla sus condiciones y políticas de datos.

Fuentes

1. Keepa. (2026). Visión general de la documentación de la API de Keepa. Recuperado de keepa.com
2. Keepa. (2026). Planes y tokens. Recuperado de keepa.com
3. Keepa. (2026). Objeto de producto e historial de precios. Recuperado de keepa.com
4. Keepa. (2026). Objeto de oferta de mercado. Recuperado de keepa.com
5. Amazon. (2026). Referencia de precios de productos de Selling Partner API. Recuperado de developer-docs.amazon.com