¿Qué es una API de catálogo en una tienda online?
Una API de catálogo es la interfaz de programación con la que una plataforma de comercio electrónico deja que otras aplicaciones lean, creen y modifiquen sus productos, categorías y variantes sin pasar por el panel. Cada aplicación entra con los permisos que el comerciante le concede, de lectura o de escritura, y lo que escribe queda guardado en la plataforma, no en el tema.
Lo esencial
- Una API de catálogo da a una aplicación acceso a los productos de la tienda sin pasar por el panel: leerlos, crearlos o cambiarlos.
- En BigCommerce se llama así, Catalog API; en Shopify, los productos se leen y se escriben con la Admin API de GraphQL.
- Leer y escribir son permisos distintos, y en Shopify el de escritura ya incluye la lectura.
- Las API de storefront sirven para enseñar el catálogo al comprador, no para cambiarlo.
- Que la API acepte un cambio dice que el dato está guardado; si la ficha lo enseña lo decide el tema o el frontend.
«API de catálogo» suena a algo que solo toca el equipo técnico, pero la ves cada vez que instalas una app: es lo que hay detrás de la pantalla en la que la app pide permiso para ver o modificar tus productos. No es un archivo de productos que la tienda exporta, ni la API con la que tu web enseña el catálogo al comprador. Es la puerta de administración del catálogo, y lo que una app puede hacer con tus fichas es exactamente lo que le dejas hacer por ella.
Cómo funciona
Una plataforma de comercio tiene dos tipos de API sobre el mismo catálogo. Las de administración leen y escriben: crean productos, cambian precios, rellenan campos. Las de storefront están hechas para el comprador. BigCommerce las describe como pensadas para las acciones de quien compra en la tienda: consultar el catálogo, iniciar sesión, llenar el carrito y pagar. Están limitadas al contexto de un comprador concreto, mientras que las de administración trabajan sin esa limitación.[1]BigCommerce Developer Learning. Storefront APIs Cuando una app tuya necesita cambiar algo, pide la primera.
En BigCommerce, la de administración se llama literalmente Catalog API: gestiona productos, categorías, marcas, reglas de precios por volumen y más, y los productos viven en la ruta /v3/catalog/products. Entre sus campos están los que importan para el SEO: page_title, meta_description, search_keywords y custom_url.[2]BigCommerce API Reference. Catalog - Products Para cambiar varios productos de una vez se usa una petición PUT a esa misma ruta con una lista de productos, cada uno con su id, y cada lote admite como máximo 10 productos.[3]BigCommerce API Reference. Update Products (batch)
En Shopify no hay una «API de catálogo» con ese nombre: los productos se leen y se escriben con la Admin API de GraphQL. La operación productUpdate cambia el título, la descripción, el fabricante o los medios de un producto, y admite también los campos de SEO (seo, con title y description) y los metafields. Lo que no hace es cambiar las variantes, que tienen su propia operación, productVariantsBulkUpdate.[4]Shopify Dev Docs. productUpdate (GraphQL Admin API)
Los permisos
Cada app entra con unos permisos concretos, que en las dos plataformas se llaman scopes. En Shopify, read_products y write_products dan acceso a los productos, sus variantes y las colecciones, entre otros recursos. Dos reglas de su documentación: un permiso de escritura incluye la lectura del mismo recurso, así que el de escritura solo se pide si la app de verdad necesita las dos cosas, y una app debe pedir solo los datos que necesita para funcionar.[5]Shopify Dev Docs. Access scopes productUpdate exige write_products.[4]Shopify Dev Docs. productUpdate (GraphQL Admin API) En BigCommerce, la lectura del catálogo es store_v2_products_read_only y la modificación, store_v2_products.[3]BigCommerce API Reference. Update Products (batch)
| Lo que hace la app | BigCommerce | Shopify |
|---|---|---|
| Leer títulos, descripciones y campos de SEO | store_v2_products_read_only |
read_products |
| Cambiar la descripción o la meta description | store_v2_products |
write_products |
Esta tabla es la que conviene tener delante cuando una app te enseña su pantalla de permisos. Una herramienta que solo informa sobre tu catálogo no necesita la segunda fila.
En una tienda
Un ejemplo ficticio: una tienda de trípodes quiere cambiar la meta description de su producto 112. En BigCommerce, la petición iría a la ruta de productos, con un lote de uno:[3]BigCommerce API Reference. Update Products (batch)
PUT https://api.bigcommerce.com/stores/{store_hash}/v3/catalog/products
Content-Type: application/json
[
{ "id": 112, "meta_description": "Trípode de viaje de carbono para cámaras sin espejo." }
]
En Shopify, la misma tarea es una mutación de GraphQL sobre el producto, con el campo seo:[4]Shopify Dev Docs. productUpdate (GraphQL Admin API)
mutation {
productUpdate(
product: {
id: "gid://shopify/Product/112"
seo: { description: "Trípode de viaje de carbono para cámaras sin espejo." }
}
) {
product {
id
}
userErrors {
field
message
}
}
}
La mutación de Shopify pide de vuelta una lista userErrors, y hay que leerla: una respuesta sin error de red puede traer dentro el cambio rechazado.[4]Shopify Dev Docs. productUpdate (GraphQL Admin API) Clione escribe en las tiendas por este mismo camino: publica sus señales con las API de la propia plataforma, y solo cuando el comerciante pulsa Push.
Lo que se suele confundir
Una respuesta correcta de la API dice que el dato está guardado, no que la ficha lo enseñe. La API escribe en la plataforma; lo que sale en la página lo decide el tema o el frontend que lee ese dato. Y dos confusiones de permisos que se repiten: dar escritura a una app que solo necesita leer, cuando Shopify recomienda pedir solo lo necesario,[5]Shopify Dev Docs. Access scopes y esperar que productUpdate cambie también las variantes, que tienen su propia operación.[4]Shopify Dev Docs. productUpdate (GraphQL Admin API)
Cómo comprobarlo
- Haz la lista de apps con acceso a tus productos y, para cada una, apunta si tiene lectura o escritura. En Shopify, los permisos que pide cada app los declara la propia app.[5]Shopify Dev Docs. Access scopes
- Compara cada permiso con lo que hace la app, con la tabla de arriba. Si solo informa, no necesita escribir.
- Si una app escribe en campos que también edita tu equipo o tu PIM, decide quién manda en cada campo, o el último en escribir gana y el otro pierde su cambio: es la sobrescritura de campos.
- Después de un cambio por API, vuelve a leer el producto con la propia API y abre el código fuente de la ficha: el primer paso confirma que el dato está guardado; el segundo, que se publica.
- En BigCommerce, divide los cambios masivos en lotes de 10 productos como máximo.[3]BigCommerce API Reference. Update Products (batch)
Concepto cercano: feed de productos
Un feed de productos es lo contrario de una puerta de administración: un archivo con los datos del catálogo, preparado con el formato que pide otro canal para que ese canal lo lea. Google Merchant Center, por ejemplo, admite los datos de producto en feeds de texto o XML, o por su propia API, y tiene su especificación de cómo deben venir.[6]Ayuda de Google Merchant Center. Product data specification La API de catálogo es la fuente; el feed es una copia que sale de ella hacia otro sitio. Y si lo que necesitas no es preguntar por los cambios sino que la plataforma te avise cuando ocurren, eso es un webhook: Shopify lo presenta como la alternativa a consultar la API una y otra vez.[7]Shopify Dev Docs. About webhooks
Para seguir, el estudio del dato guardado al dato publicado mide la distancia entre lo que acepta la API y lo que sale en la ficha, y la ruta de lectura de publicación por plataforma ordena el resto de términos.
Sinónimos
- English
- catalog API, products API
- Español
- API de productos
Fuentes
- [1] BigCommerce Developer Learning. Storefront APIs. Consultado el . ↑
- [2] BigCommerce API Reference. Catalog - Products. Consultado el . ↑
- [3] BigCommerce API Reference. Update Products (batch). Consultado el . ↑ ↑ ↑ ↑
- [4] Shopify Dev Docs. productUpdate (GraphQL Admin API). Consultado el . ↑ ↑ ↑ ↑ ↑
- [5] Shopify Dev Docs. Access scopes. Consultado el . ↑ ↑ ↑
- [6] Ayuda de Google Merchant Center. Product data specification. Consultado el . ↑
- [7] Shopify Dev Docs. About webhooks. Consultado el . ↑
Historial de cambios
- Primera versión.
Esta definición se publica bajo licencia CC BY 4.0. Puedes reutilizar esta definición citando a Clione con un enlace a esta página.
Términos relacionados
Webhook
Qué es un webhook, cómo avisan Shopify y BigCommerce de un cambio en el catálogo y por qué un aviso no sustituye a una sincronización periódica.
Versionado de contenido
Qué es el versionado de contenido, en qué se distinguen historial, borrador y versión publicada, y cómo comprobar que puedes volver atrás en tu tienda.
Catalyst
Qué es Catalyst, el frontend de BigCommerce sobre Next.js, qué deja de hacer el tema Stencil y qué revisar para que buscadores y asistentes lean tu tienda.
Metafields
Qué son los metafields de Shopify, de qué partes constan, cómo llegan del panel al HTML de la ficha y cómo comprobar que tu tema los publica.
Custom fields
Qué son los custom fields de BigCommerce, sus límites (200 por producto), cómo los pinta un tema Stencil y en qué se diferencian de los metafields.
Sobrescritura de campos
Qué es la sobrescritura de campos: cuando una app, un PIM o una sincronización pisa un dato de producto que escribió otro sistema, y cómo detectarla.
Haz que los bots entiendan tu catálogo
Clione completa cada ficha de producto con lo que los bots leen mejor: el grafo JSON-LD con sus datos estructurados, la meta description y las preguntas frecuentes. Tú revisas y pulsas Push; después comprobamos tu tienda en vivo para que todo siga publicado.