Skip to main content
Usa la API de Matching para refrescar el Price Radar de tu organización desde un scraper programado, un pipeline de matching o una integración de un partner. Acepta las mismas exportaciones de competidores en bruto o ya emparejadas que Update (actualizar) en la página de matching de competidores, con la misma validación, los mismos controles de cobertura y el mismo comportamiento de publicación. Tanto la solicitud de carga como la de progreso usan tu clave Bearer de la API pública. No se requiere una sesión de navegador iniciada.

​
Elige la carga correcta

El endpoint de Matching acepta un CSV UTF-8. La cabecera decide cómo se procesa:
  • item_id está presente: el archivo se trata como ya emparejado y se publica contra tu catálogo.
  • item_id está ausente: Price Radar empareja la exportación de competidores en bruto con tu catálogo antes de la publicación.
  • Un archivo en bruto también debe omitir las columnas de enlace external_match_id, match_relation, match_method y match_confidence. Un archivo que contenga cualquiera de esas columnas sin item_id se rechaza.
El nombre matched-snapshots cubre ambos tipos de archivo; no hay un endpoint separado para cargas en bruto ni un parámetro de tipo de carga. Usa el mismo formato de exportación que subirías en la página de matching de competidores. La cabecera del CSV debe caber en 64 KiB.

​
Subir un archivo

La solicitud multipart completa debe tener como máximo 25 MiB (26.214.400 bytes), incluidos los campos del formulario y la sobrecarga multipart. Mantén el archivo por debajo de ese total. Deja que curl establezca el Content-Type multipart y el boundary. Con cobertura partial (parcial), los precios de competidores fuera de covered_competitors se mantienen. Una entrega parcial sin competidores cubiertos añade lo que trae y no retira nada. Con cobertura full (completa), el archivo declara el conjunto completo y puede retirar las coincidencias que omite; covered_competitors no acota esa declaración.
Elige full solo cuando el archivo sea una entrega completa. Revisa la exportación antes de establecer allow_large_removal=true; esta confirmación permite que una eliminación inusualmente grande siga adelante.
Una carga correcta devuelve 202 Accepted y un identificador de trabajo:
Esto significa que la publicación se puso en cola. La validación, el matching de los archivos en bruto y la publicación continúan en segundo plano. Guarda el ID del trabajo y síguelo hasta un estado terminal.

​
Seguir la publicación

Consulta el endpoint de progreso específico de Matching con la misma clave de API:
Este endpoint incluye el progreso, los recuentos y las filas rechazadas. Úsalo para estos trabajos en lugar del endpoint genérico /v1/jobs/{job_id}.
status es queued, running, cancelling, completed, failed o cancelled. Los tres últimos son terminales. Consulta cada 5-10 segundos mientras está en ejecución y cada 30-60 segundos mientras está en cola; el sondeo consume el presupuesto de uso compartido de la organización. Dentro de result_summary, accepted es el número de filas aceptadas, rejected es el total de filas rechazadas y sent es el total de filas procesadas. Revisa estos recuentos incluso cuando status sea completed: un archivo publicado puede contener filas rechazadas. row_errors contiene una muestra de como máximo 200 rechazos, cada uno con line, code, message e item_id. El ID del ítem puede estar vacío, por ejemplo cuando una fila en bruto no tiene coincidencia en el catálogo. No es un informe completo de rechazos. La muestra puede ser más corta que rejected, o estar vacía si no se pudieron recuperar los detalles del rechazo; usa rejected para el total.

​
Gestionar conflictos y fallos

Los fallos de validación del CSV y de publicación en el sistema de destino pueden ocurrir después del 202; aparecen como un trabajo terminal failed. Revisa error_message y los rechazos de filas disponibles, corrige la entrada o espera a que se resuelva un problema temporal del servicio, y luego envía una nueva carga. La publicación y el progreso se comparten dentro de la organización. Otro usuario con clave de API en la misma organización puede seguir el trabajo; un usuario de otra organización no. Solo se ejecuta una entrega de matching a la vez entre las cargas por API y las cargas desde la aplicación.

​
Relacionado