Cómo utilizar una Amazon Search API para obtener datos de productos en aplicaciones

Escrito por Evan Huang

Publicado el 14 de agosto de 2026 • 15 min de lectura

Una Amazon Search API proporciona a una aplicación acceso estructurado a datos de búsqueda de productos sin que una persona copie resultados de las páginas de la tienda. Según el proveedor y el uso, la respuesta puede respaldar descubrimiento de productos, comprobaciones de posiciones de palabras clave, comparación de precios, análisis de anuncios patrocinados, seguimiento de competidores o consultas de catálogo. La dificultad es que «Amazon Search API» puede describir varios productos diferentes con permisos y salidas distintos.

Esta guía distingue esas opciones y muestra una implementación completa con Amazon Search API de Nexscope. Los detalles de solicitudes y respuestas siguientes siguen la documentación de Nexscope revisada para publicación el 14 de agosto de 2026. El recorrido cubre el endpoint de producción, autenticación bearer, los ocho parámetros documentados, la respuesta directa y la gestión práctica de errores. También explica cuándo encajan mejor Amazon Business Product Search, Amazon Creators API o Catalog Items API de Selling Partner API. Al terminar, un desarrollador podrá enviar búsquedas por palabra clave, analizar el array products, conservar las posiciones patrocinadas y orgánicas y convertir resultados de la tienda en directo en un flujo fiable de investigación de comercio electrónico.

Fundamentos de Amazon Search API

Una Amazon Search API acepta una intención de búsqueda, como una palabra clave o consulta de catálogo, y devuelve datos de productos legibles por máquinas. Una API orientada a la tienda suele reflejar la experiencia de búsqueda del comprador. Una API de catálogo se centra en registros oficiales de artículos. Una API de compras sirve a procesos de aprovisionamiento. Una API de afiliados respalda el descubrimiento de productos y las experiencias de recomendación.

Esta distinción importa porque la misma palabra clave puede producir salidas muy distintas. Una búsqueda de tienda puede incluir ubicaciones patrocinadas, posición del resultado, precio mostrado, número de valoraciones, texto de entrega e insignias. Una consulta de catálogo puede ofrecer atributos más completos sin mostrar el orden exacto en que un comprador vio los productos para una palabra clave. La aplicación debe elegir la fuente que corresponda a la decisión que necesita tomar.

Los usos habituales de búsqueda de tienda incluyen:

• Comprobar dónde aparece un ASIN para una palabra clave objetivo
• Separar ubicaciones patrocinadas de anuncios orgánicos
• Comparar precios mostrados entre productos de una página de búsqueda
• Descubrir marcas competidoras y anuncios nuevos
• Supervisar cambios en la composición de la primera página de resultados
• Recopilar entradas en directo para investigación de productos o análisis de mercado

Los resultados de búsqueda dependen del contexto. El dominio del marketplace, idioma, ubicación de entrega, dispositivo, ordenación, nodo de categoría y número de página pueden afectar al conjunto devuelto. Por ello, cada resultado almacenado debe conservar su contexto de solicitud y hora de recopilación. Una posición de producto sin esos detalles puede inducir a error.

Cuatro opciones de API

La mejor Amazon Search API depende de la aplicación. Las cuatro opciones siguientes resuelven problemas distintos y no deben tratarse como intercambiables.

Nexscope Amazon Search

Nexscope documenta Amazon Search como una simulación de tienda para obtener posiciones de palabras clave y resultados de búsqueda en tiempo real. Los usos compatibles incluyen búsqueda de productos, comprobaciones de posición de ASIN, descubrimiento de competidores, comparación de precios, análisis de productos patrocinados, seguimiento de productos nuevos y análisis de SERP de tienda.

La API es adecuada cuando una aplicación necesita observar qué aparece en una búsqueda de Amazon. Devuelve directamente la respuesta del proveedor de origen, sin envoltorios adicionales data o result. No sirve para flujos de pedidos, inventario o administración de cuentas de Amazon.

Amazon Business Search

Amazon Business Product Search sirve a experiencias de aprovisionamiento y compras empresariales. Su documentación oficial describe un flujo en el que una integración inicia una búsqueda y trabaja con datos de compras de Amazon Business. Es la vía pertinente cuando la aplicación se centra en compras de organizaciones y no en investigación de marketplaces.

Amazon Creators API

Amazon Creators API incluye SearchItems para descubrir productos por palabras clave y otros criterios. Pertenece al ecosistema de afiliados y creadores. Las aplicaciones deben cumplir sus requisitos de acceso, contenido y enlaces. Encaja con el descubrimiento de productos para experiencias aprobadas de afiliados, no con la recopilación sin restricciones de observaciones de posiciones de tienda.

SP-API Catalog Items

Catalog Items API de Selling Partner API permite buscar y obtener artículos de catálogo para vendedores y proveedores autorizados. Sirve para identificadores, atributos, imágenes, relaciones y otros datos de artículos cubiertos por el recurso y marketplace seleccionados. No debe sustituir una página de resultados por palabra clave en directo cuando se necesita la condición de patrocinado y la posición observada en SERP.

Parámetros de solicitud de Nexscope

El endpoint de producción de Nexscope es:

POST https://api.nexscope.ai/api/skill-api/v1/skills/amazon-search/run

Cada solicitud de ejecución requiere una clave API de usuario en la cabecera Authorization y un cuerpo JSON. La documentación actual enumera ocho parámetros. Están marcados como opcionales en el esquema, aunque una búsqueda útil normalmente proporciona al menos keyword.

Valores de ordenación

Los valores documentados de sort son:

La solicitud debe explicitar sus supuestos de marketplace. Por ejemplo, una búsqueda estadounidense puede combinar amazon.com, en_US y un código postal de entrega estadounidense pertinente. Una búsqueda alemana debe utilizar una palabra clave en alemán, el dominio de Amazon correspondiente y de_DE. Esto mejora la reproducibilidad y reduce la ambigüedad al comparar resultados después.

Primera solicitud API

Empieza creando una clave API en la página de acceso API de Nexscope. Los nuevos usuarios reciben 1,000 créditos gratuitos. El plan de pago más económico cuesta $9 al mes e incluye 3,000 créditos mensuales.

Guarda la clave en una variable de entorno del servidor. Nunca debe incrustarse en JavaScript del navegador, guardarse en un repositorio ni escribirse en eventos analíticos.

Solicitud cURL mínima

El ejemplo documentado utiliza phone case y la página 1:

curl -X POST \
  "https://api.nexscope.ai/api/skill-api/v1/skills/amazon-search/run" \
  -H "Authorization: Bearer $NEXSCOPE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "keyword": "phone case",
    "page": 1
  }'

La API devuelve directamente su respuesta específica. El código debe leer campos de nivel superior como keyword, total y products, en lugar de esperar data.products.

Solicitud con contexto

Una consulta de tienda estadounidense más reproducible puede incluir el contexto de búsqueda:

curl -X POST \
  "https://api.nexscope.ai/api/skill-api/v1/skills/amazon-search/run" \
  -H "Authorization: Bearer $NEXSCOPE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "keyword": "phone case",
    "amazonDomain": "amazon.com",
    "language": "en_US",
    "sort": "relevanceblender",
    "page": 1,
    "deliveryZip": "10001",
    "device": "desktop"
  }'

Utiliza node solo cuando el flujo necesite limitar la búsqueda por categoría. Añadir un nodo cambia el contexto, por lo que los resultados limitados por nodo no deben compararse con búsquedas sin restricciones como si representaran la misma SERP.

Solicitud en JavaScript

El siguiente ejemplo de JavaScript del servidor valida la respuesta HTTP antes de utilizar los datos:

const endpoint =
  "https://api.nexscope.ai/api/skill-api/v1/skills/amazon-search/run";

const response = await fetch(endpoint, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.NEXSCOPE_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    keyword: "phone case",
    amazonDomain: "amazon.com",
    language: "en_US",
    page: 1,
    deliveryZip: "10001",
    device: "desktop",
  }),
});

if (!response.ok) {
  const errorBody = await response.text();
  throw new Error(`Amazon search failed: ${response.status} ${errorBody}`);
}

const payload = await response.json();
const products = Array.isArray(payload.products) ? payload.products : [];

La solicitud corresponde a un backend fiable porque contiene la clave API. Una aplicación de navegador puede llamar a su propia ruta de backend, que valide la entrada del usuario, aplique cuotas, llame a Nexscope y devuelva solo los campos necesarios para la interfaz.

Datos de respuesta

La respuesta documentada de nivel superior incluye total, keyword, type, columns, costToken y products. También puede incluir campos de estado del proveedor como errcode, errmsg, code, msg, message o title, además de metadatos de paginación y ejecución cuando los proporcione el proveedor de origen.

El array products es el conjunto principal de resultados. El esquema actual documenta estos grupos útiles de campos:

Todos los campos del esquema de respuesta son opcionales. Un analizador de producción debe admitir valores ausentes. Por ejemplo, un valor ausente de monthlySalesUnits debe permanecer como null o desconocido. No debe convertirse silenciosamente en cero.

Registro normalizado de producto

Una aplicación puede reducir el objeto de origen a un registro interno estable conservando la respuesta original para depuración:

function normalizeProduct(product, context) {
  return {
    asin: product.asin ?? null,
    title: product.title ?? null,
    brand: product.brand ?? null,
    price: product.extractedPrice ?? product.price ?? null,
    oldPrice: product.extractedOldPrice ?? product.oldPrice ?? null,
    currency: product.currency ?? null,
    rating: product.rating ?? null,
    ratingCount: product.ratings ?? null,
    position: product.position ?? null,
    sponsored: product.sponsored ?? null,
    imageUrl: product.imageUrl ?? null,
    productUrl: product.asinUrl ?? null,
    keyword: product.keyword ?? context.keyword,
    marketplace: context.amazonDomain,
    page: context.page,
    deliveryZip: context.deliveryZip,
    device: context.device,
    collectedAt: new Date().toISOString(),
  };
}

Mantén sponsored como booleano o null. Convertir un valor ausente a false puede clasificar incorrectamente una ubicación desconocida como orgánica. El mismo principio se aplica a precio, posición, valoración y estimaciones de ventas.

Flujo de la aplicación

Una integración útil hace más que una sola solicitud. Define un recorrido repetible desde la planificación de consultas hasta el análisis.

1. Define el contexto de búsqueda

Crea un registro de consulta con palabra clave, dominio del marketplace, idioma, nodo de categoría si se usa, ordenación, intervalo de páginas, código postal de entrega y dispositivo. Este registro se convierte en la clave de comparación para ejecuciones posteriores.

Para investigar palabras clave, empieza con un conjunto manejable de frases vinculadas a una hipótesis de producto. Si el flujo aún está decidiendo qué supervisar, un proceso estructurado de investigación de productos de Amazon puede ayudar a conectar las observaciones de búsqueda con preguntas de demanda, competencia, precios y diferenciación.

2. Obtén páginas de resultados

Solicita primero la página 1 e inspecciona el recuento y el conjunto devueltos. Añade más páginas solo si el uso necesita mayor cobertura. Respeta los límites de la cuenta y evita solicitar contextos idénticos con más frecuencia de la que requiere la decisión de negocio.

Guarda la respuesta original con un identificador de solicitud. Conservarla permite investigar cambios de análisis, comportamiento de campos opcionales o mensajes inesperados del proveedor sin repetir inmediatamente la llamada.

3. Normaliza los productos

Convierte cada producto a un esquema interno estable. Conserva ASIN, campos de precio mostrado y analizado, divisa, valoración, número de valoraciones, posición, condición de patrocinado y metadatos de origen. Guarda el contexto de búsqueda junto a cada fila de producto.

La deduplicación debe utilizar algo más que el título. ASIN es el identificador de producto documentado más sólido de esta respuesta. Si el mismo ASIN aparece varias veces por una ubicación o comportamiento de variantes, conserva cada ubicación observada en la tabla original de resultados y vincula esas observaciones a una entidad de producto.

4. Separa los tipos de ubicación

Los productos patrocinados y los resultados orgánicos responden a preguntas diferentes. La ubicación patrocinada sirve para analizar densidad publicitaria y publicidad de competidores. La posición orgánica es relevante para la visibilidad de tienda. Un promedio combinado puede ocultar la distinción.

Guarda como mínimo estos valores derivados:

• absolutePosition: el valor documentado de position
• placementType: sponsored, organic o unknown
• page: el número de página solicitado
• queryContextId: una referencia al marketplace, idioma, código postal, dispositivo y ordenación

Los equipos que conectan observaciones de búsqueda con decisiones publicitarias pueden combinar estos datos con una estrategia de PPC de Amazon. La API de búsqueda muestra la composición observada de la tienda; los datos de rendimiento publicitario siguen siendo un conjunto separado.

5. Crea salidas para la toma de decisiones

Los registros normalizados pueden alimentar un monitor de posiciones, una tabla de competidores, una distribución de precios, un informe de cuota patrocinada o una cola de descubrimiento de productos. Cada salida debe mostrar cuándo se recopilaron los datos y qué contexto de búsqueda los produjo.

Los datos de búsqueda también pueden orientar el trabajo de anuncios. Un vendedor puede revisar patrones recurrentes de títulos, umbrales de valoración, franjas de precio e insignias entre competidores visibles y utilizar esas observaciones como entradas para la optimización de anuncios de Amazon. Los resultados por sí solos no demuestran por qué se posiciona un producto, por lo que las decisiones deben combinar observaciones de SERP con datos de producto, publicidad, conversión y cuenta.

Fiabilidad en producción

La documentación enumera resultados HTTP estándar que deben orientar la lógica de reintentos y alertas.

Política de reintentos

Reintenta solo fallos transitorios. Una política práctica utiliza esperas exponenciales con variación aleatoria para respuestas 429 y determinadas 5xx. Limita el número de intentos y registra el error final. Repetir una solicitud 400, 401 o 403 sin cambiar su causa desperdicia créditos y oculta el problema subyacente.

Validación del esquema

Valida la respuesta de nivel superior antes de procesarla. products debe tratarse como array solo cuando realmente lo sea. Cada elemento debe analizarse campo a campo porque el esquema los marca como opcionales. Los campos de mensajes específicos del proveedor deben registrarse de forma segura y estructurada.

Estrategia de caché

La caché debe ajustarse a la actualización que necesita el flujo. Un panel de investigación de productos puede admitir una caché más larga que un monitor de posiciones de intervalo corto. Utiliza una clave que incluya todos los parámetros capaces de cambiar la vista de la tienda. Guardar solo por palabra clave puede mezclar dominios, idiomas, códigos postales, dispositivos, ordenaciones, nodos o páginas diferentes.

Observabilidad

Registra duración de solicitud, código de estado, número de resultados, metadatos de página devueltos, coste de créditos cuando esté disponible, número de reintentos y un identificador no secreto. Nunca registres el token bearer. Las alertas deben distinguir fallos de autenticación, limitación de frecuencia, fallos de origen y conjuntos de resultados válidos vacíos o parciales.

Errores comunes de implementación

Los problemas más costosos suelen provenir de interpretar mal los datos, no de redactar la solicitud HTTP.

Mezclar finalidades de API

Nexscope Amazon Search, Amazon Business Product Search, Creators API SearchItems y SP-API Catalog Items sirven a flujos diferentes. Selecciona la API según la decisión y permisos necesarios, no por compartir la palabra «búsqueda».

Esperar un envoltorio

El endpoint de ejecución de Nexscope devuelve directamente los datos de la API. El código que busca solo data.products o result.products puede tratar una respuesta válida como vacía. Lee products en el nivel superior.

Descartar el contexto de búsqueda

Una palabra clave y una posición están incompletas sin marketplace, página, idioma, código postal, dispositivo, ordenación, nodo y hora de recopilación. Guarda el contexto completo con cada observación.

Fusionar pago y orgánico

La respuesta documenta un campo sponsored. Consérvalo. Un informe que combine ubicaciones de pago con visibilidad orgánica puede producir una conclusión equivocada.

Tratar lo ausente como cero

Los campos de respuesta son opcionales. Los valores ausentes de precio, ventas, valoración o patrocinio deben permanecer desconocidos salvo que una regla documentada respalde otra interpretación.

Exponer la clave API

La autenticación bearer corresponde a un servidor fiable. Evita claves del lado del cliente, archivos .env guardados en el repositorio, capturas con credenciales reales y registros que capturen cabeceras de autorización.

Suponer cobertura histórica

La capacidad documentada de Amazon Search devuelve resultados en directo, no analítica histórica de términos de búsqueda. Las comparaciones históricas requieren que la aplicación recopile instantáneas coherentes a lo largo del tiempo o utilice un conjunto histórico separado.

Llamar en exceso al endpoint

Las llamadas repetidas con contexto idéntico pueden consumir créditos sin aportar valor a la decisión. Define la frecuencia necesaria, utiliza caché, aplica esperas ante límites y supervisa el consumo de créditos.

El catálogo más amplio de Amazon Data API de Nexscope puede respaldar flujos relacionados de productos, competidores, palabras clave, reseñas, ventas, mercados y compras mediante una capa API independiente. Los datos compatibles pueden conectarse al propio agente del usuario mediante REST API o MCP, o utilizarse en el producto web de Nexscope.

Explora el catálogo más amplio de Amazon Data API

Conecta datos estructurados de productos, competidores, palabras clave, reseñas, ventas y mercados de Amazon a aplicaciones o al propio agente del usuario mediante REST API o MCP.

Explora Amazon Data API →

Conclusión

Una integración de Amazon Search API empieza con una definición precisa de la experiencia de búsqueda necesaria. Utiliza Nexscope Amazon Search para analizar resultados de tienda en directo, incluidos posición, precio, valoración y condición de patrocinado. Utiliza Amazon Business Product Search para compras empresariales, Creators API SearchItems para descubrimiento aprobado de afiliados y SP-API Catalog Items para datos de catálogo autorizados.

Para implementar Nexscope, envía una solicitud JSON autenticada con bearer al endpoint de ejecución amazon-search de producción, conserva todo el contexto, analiza el array products de nivel superior y trata todos los campos documentados como opcionales. Separa ubicaciones patrocinadas y orgánicas, conserva las respuestas originales, reintenta solo fallos transitorios y guarda marcas temporales para comparaciones futuras.

El esquema completo de parámetros y respuestas está disponible en la documentación de Amazon Search API de Nexscope. Esa página debe seguir siendo la referencia cuando cambien el endpoint, esquema, cobertura o reglas de cuenta.

Preguntas frecuentes

¿Existe una Amazon Search API oficial?

Amazon proporciona varias API oficiales con funciones de búsqueda, pero sirven a programas distintos. Amazon Business Product Search respalda integraciones de compras empresariales. Amazon Creators API incluye SearchItems para experiencias aprobadas de creadores y afiliados. Catalog Items API de Selling Partner API respalda flujos de catálogo de vendedores y proveedores autorizados. No debe suponerse automáticamente que ninguna reproduce una página de resultados por palabra clave visible al comprador. Un proveedor de datos de búsquedas de tienda como Nexscope es una opción separada para analizar SERP y posiciones en directo.

¿Qué devuelve Amazon Search API de Nexscope?

La respuesta documentada es directa, con campos de nivel superior que pueden incluir total, keyword, columns, costToken y products. Los objetos de producto pueden incluir ASIN, título, marca, precios actuales y anteriores, divisa, valoración, número de valoraciones, posición, condición de patrocinado, URL de imagen, enlace del producto, entrega, gestión logística, señales del anuncio, estimaciones de ventas y metadatos de origen. El esquema marca estos campos como opcionales, por lo que las aplicaciones deben manejar con seguridad los resultados parciales.

¿Qué parámetros puede utilizar una solicitud de búsqueda de Amazon?

La documentación de Nexscope enumera ocho parámetros opcionales: keyword, amazonDomain, node, language, sort, page, deliveryZip y device. El marketplace predeterminado es amazon.com, la página predeterminada es 1 y el dispositivo predeterminado es desktop. Las opciones de ordenación documentadas incluyen destacados, precio ascendente, precio descendente, valoración media de clientes, novedades y más vendidos. Un flujo reproducible guarda todos los parámetros proporcionados junto a los resultados.

¿Puede la API comprobar la posición de un ASIN para una palabra clave?

Sí. Nexscope documenta la comprobación de posiciones de ASIN como uso compatible de su simulación de búsqueda de tienda. Busca la palabra clave objetivo, examina el array products y encuentra el ASIN objetivo. Conserva position, sponsored, página, marketplace, idioma, código postal de entrega, dispositivo, ordenación y hora de recopilación. Una sola observación es solo una instantánea. Los informes de tendencias requieren recopilaciones repetidas y coherentes con el mismo contexto.

¿Se pueden separar productos patrocinados de resultados orgánicos?

Sí. El esquema documentado incluye products[].sponsored como booleano cuando se proporciona. Las aplicaciones deben mantener separadas las observaciones patrocinadas y orgánicas porque representan mecanismos distintos de visibilidad. Cuando el campo falte, clasifica la ubicación como desconocida, no automáticamente como orgánica. Así se evita convertir datos ausentes en una conclusión falsa sobre posiciones de pago u orgánicas.

¿Proporciona la API datos históricos de búsquedas de Amazon?

La documentación de Amazon Search de Nexscope describe la capacidad como búsqueda de tienda en tiempo real y la presenta explícitamente como resultados en directo, no como analítica histórica de términos. Una aplicación puede crear su propio historial guardando instantáneas programadas con parámetros y marcas temporales coherentes. Los flujos que necesiten un conjunto histórico existente deben elegir otra capacidad diseñada para analítica histórica y verificar su cobertura antes de implementar.

¿Cómo deben gestionarse los límites y errores?

Valida la entrada antes de enviarla, detente ante errores de autenticación o acceso y reintenta solo fallos transitorios. La documentación identifica 400 para solicitudes inválidas, 401 para claves ausentes o inválidas, 403 para acceso insuficiente, 429 para limitación de frecuencia y 5xx para fallos de API o del origen. Utiliza esperas exponenciales con variación aleatoria para 429 y determinadas respuestas 5xx, limita los intentos y nunca registres el token bearer.

¿Puede Amazon Search API conectarse a un agente de IA?

Sí. Nexscope documenta dos vías programáticas. La aplicación o el agente del usuario puede llamar directamente al endpoint REST, y también dispone de acceso MCP mediante la herramienta documentada nexscope_amazon_search y el flujo JSON-RPC. Las mismas capacidades pueden utilizarse en el producto web de Nexscope. La salida del agente debe conservar el contexto de origen, los límites de campos opcionales y la condición de patrocinado, en lugar de convertir datos inciertos en afirmaciones definitivas.

Fuentes

1. Nexscope. (2026). Documentación de Amazon Search API. Consultado en nexscope.ai
2. Amazon Business. (2026). Descripción general de Product Search API. Consultado en docs.business.amazon.com
3. Amazon Associates. (2026). Creators API SearchItems. Consultado en affiliate-program.amazon.com
4. Amazon Selling Partner API. (2026). Referencia de Catalog Items API v2022-04-01. Consultado en developer-docs.amazon.com