Saltar al contenido
UCP
Menú

Recursos · Ensayo

Catálogo como API

Tratar el catálogo de productos como una superficie de API deliberada, versionada, tipada y documentada. El cambio de mentalidad, las implicaciones operativas.

Publicado : ·10 min de lectura ·Consulta : API de catálogo de productos

La mayoría de los comerciantes tratan su catálogo de productos como datos, un conjunto de registros almacenados en un PIM, sincronizados con una tienda online, exportados como un feed. Ese enfoque ya no es suficiente. Un agente no consume sus datos como datos; consume su catálogo como si fuera una API. Una vez que se percibe el cambio, la práctica operativa cambia en consecuencia.

El enfoque

Las API tienen cuatro propiedades que los catálogos generalmente no tienen: contrato, control de versiones, documentación y garantías de fiabilidad. Los agentes explotan las cuatro. Si su catálogo carece de ellas, el agente compensa mediante conjeturas, scraping y una menor confianza, todo lo cual penaliza su visibilidad.

Contrato

Un contrato de API define qué campos existen, qué tipos contienen, qué rangos aceptan. Un contrato de catálogo significa:

  • Cada producto tiene campos de identificador (GTIN, MPN+Marca).
  • Los campos de precio son tipados (número + moneda), no cadenas.
  • La disponibilidad se enumera (in_stock / out_of_stock / pre_order / back_order).
  • Las políticas son objetos estructurados, no prosa.
  • Los atributos personalizados tienen tipos y unidades declarados.

El contrato puede residir en múltiples lugares: el JSON-LD en sus PDPs, su esquema de feed e, idealmente, un esquema legible por máquina publicado en una URL estable. Trátelo como fuente de verdad.

Control de versiones

Las API tienen versiones. Los catálogos rara vez. El resultado: cuando un comerciante cambia el significado de un atributo ("Tiempo de envío" solía significar manipulación + tránsito, ahora solo tránsito), cada consumidor descendente se rompe silenciosamente. Los agentes que han almacenado en caché interpretaciones anteriores están equivocados.

Un contrato de catálogo debe llevar un número de versión. Los cambios importantes deben aumentarlo. Las adiciones no importantes deben ser claras. Las deprecaciones deben anunciarse. La disciplina cuesta poco y previene el modo de fallo silencioso más común en las operaciones de feed.

Documentación

La documentación para un catálogo significa:

  • Una descripción pública de cada atributo que expone.
  • Convenciones de unidades (cm vs pulgadas, gramos vs oz).
  • Valores enumerados y sus significados (estados de disponibilidad).
  • SLAs de frescura ("inventario actualizado cada 10 minutos").
  • Esquemas de políticas (qué campos lleva su estructura de devoluciones).

La mayoría de los comerciantes no escriben nada de esto. Los líderes lo publican. Hacerlo alinea los marketplaces, los socios afiliados, los agentes y sus propios equipos internos.

Fiabilidad

Las API se comprometen con la fiabilidad. Los catálogos también deberían hacerlo. Los dos compromisos medibles:

  • Paridad entre superficies (feed, PDP, checkout). La inconsistencia es tratada por los agentes como falta de fiabilidad.
  • Frescura: una cadencia de actualización declarada que se cumple.

"Nuestro feed se actualiza cada 15 minutos" es un compromiso. "Actualizamos el feed cuando nos acordamos" es un modo de fallo que los agentes miden.

Implicaciones para las operaciones

  1. Tener un registro de cambios del catálogo. Publíquelo donde los socios y agentes puedan encontrarlo. Incluso un simple archivo Markdown con fecha en /catalog/changelog es mejor que el silencio.
  2. Alinear fuentes. El PIM es la fuente de verdad. El feed y el PDP se renderizan a partir de él. Cualquier divergencia es un error.
  3. Tipar sus atributos personalizados. Si tiene "Warranty_Length" como una cadena de formato libre, conviértalo a un entero con unidades.
  4. Exponer un endpoint de lectura. Si los orquestadores de agentes quieren llamarle directamente (a través de MCP, por ejemplo), publique un endpoint de catálogo simple.
  5. Medir la paridad. Tarea nocturna: muestrear 100 SKUs, comparar feed vs PDP vs checkout, alertar sobre deltas >1%.

El cambio de mentalidad

"Catálogo" suena a artefacto estático. "API" suena a sistema vivo con usuarios. Una vez que ve su catálogo como un sistema vivo con usuarios externos, usuarios que le citarán, le compararán y transaccionarán con usted, el nivel de disciplina ambiental aumenta. Los campos se nombran mejor. Las unidades se declaran explícitamente. Las deprecaciones se anuncian. La paridad se mide. Ese es el objetivo principal del enfoque.

Dónde ir a continuación