APIs, conectores y middleware: un glosario para perfiles no técnicos que trabajan en proyectos PIM
Términos técnicos que aparecen constantemente en proyectos de integración, explicados en lenguaje accesible para perfiles de negocio y contenido.
La primera vez que participamos en una reunión de integración PIM puede parecer que todo el mundo empezó a hablar otro idioma de golpe.
API. Endpoint. JSON. Webhook. Token. Mapping. Middleware. Request. Payload. Sincronización delta.
Y, en algún momento, alguien pregunta si el conector va a hacer un PATCH.
Para trabajar en un proyecto PIM no necesitamos saber programar, pero sí necesitamos entender cómo se mueve la información entre sistemas. Detrás de esos términos técnicos hay preguntas que afectan directamente nuestro trabajo: qué dato sale del ERP, cuál llega al PIM, qué información se publica en el eCommerce, qué se transforma en el medio y qué pasa cuando algo falla.
Mi forma de pensarlo es bastante simple: una integración es un flujo de trabajo entre sistemas. El equipo técnico construye el mecanismo, pero quienes trabajamos con producto, contenido o negocio necesitamos entender qué debería viajar por ese mecanismo y qué resultado esperamos obtener.
Este glosario no pretende convertirnos en desarrolladores. La idea es que podamos entrar a una reunión de integración, seguir la conversación y hacer las preguntas correctas.
No hace falta saber escribir una API para participar en una integración PIM. Sí hace falta entender qué información entra, cuál sale, quién la transforma y dónde debería terminar.
¿Qué significa integrar un PIM con otros sistemas?
Una integración permite que dos o más sistemas intercambien información de manera controlada.
En un ecosistema de producto podríamos tener, por ejemplo:
El ERP crea un artículo con su SKU y determinados datos operativos. El PIM recibe esa información y el equipo la enriquece con títulos, atributos, descripciones, categorías e imágenes. Después, la información preparada para venta se publica en el eCommerce.
La flecha que dibujamos entre esos sistemas parece sencilla, pero en realidad representa muchas decisiones.
¿Cómo sale el dato del ERP? ¿Cómo entra al PIM? ¿Qué atributos se envían? ¿Hay que transformar algún valor? ¿La actualización ocurre cada cinco minutos o una vez por día? ¿Qué sistema tiene autoridad sobre cada campo? ¿Qué pasa si el destino rechaza un producto?
Las APIs, los conectores y el middleware son algunas de las herramientas que permiten resolver esas preguntas.
¿Cuál es la diferencia entre API, conector y middleware?
Estos tres conceptos aparecen juntos constantemente, pero no significan lo mismo.
| Concepto | Explicación simple | Para qué sirve |
|---|---|---|
| API | Interfaz que permite comunicarse con un sistema | Consultar, crear o modificar información |
| Conector | Solución preparada para vincular sistemas concretos | Resolver parte de una integración ya conocida |
| Middleware | Capa intermedia entre varios sistemas | Coordinar, transformar, validar y distribuir datos |
Podemos imaginar una cocina.
La API sería la puerta por la que podemos entregar y recibir ingredientes.
El conector sería una receta ya preparada para comunicar dos cocinas concretas.
El middleware sería la mesa de trabajo donde podemos recibir ingredientes de distintos lugares, revisar cantidades, transformar preparaciones y decidir qué enviamos a cada destino.
No es una definición técnica perfecta, pero ayuda a entender la función de cada pieza.
Una API permite comunicarse. Un conector resuelve una conexión concreta. Un middleware organiza lo que ocurre entre sistemas. Son partes relacionadas, pero no intercambiables.
¿Qué es una API?
API significa Application Programming Interface. Es una interfaz que establece cómo otra aplicación puede comunicarse con un sistema.
Una API puede permitir, por ejemplo:
- consultar un producto;
- crear un registro;
- actualizar atributos;
- obtener categorías;
- descargar información de imágenes;
- recuperar variantes;
- modificar relaciones entre productos.
En un proyecto PIM, las APIs son especialmente importantes porque permiten que el sistema intercambie información con ERPs, eCommerce, DAM, marketplaces y otras aplicaciones.
Pero hay una diferencia que conviene recordar:
tener una API disponible no significa tener una integración resuelta.
La API nos ofrece el mecanismo de comunicación. Después necesitamos decidir qué información vamos a intercambiar, cómo se relacionan los campos, qué transformaciones hay que aplicar, cuándo debe ejecutarse el proceso y cómo vamos a controlar los errores.
¿Qué es una API REST?
REST es una forma muy extendida de diseñar APIs que trabajan sobre recursos mediante HTTP.
Para un perfil no técnico, no es necesario profundizar en toda su arquitectura. Lo útil es reconocer algunos métodos que aparecen habitualmente en las conversaciones:
| Método | En términos prácticos |
|---|---|
GET | Consultar información |
POST | Enviar información o solicitar la creación de algo |
PATCH | Aplicar cambios parciales |
DELETE | Solicitar la eliminación de un recurso |
Si durante una reunión alguien dice:
«Hacemos un GET de los productos modificados y después un PATCH al PIM».
Podemos traducirlo mentalmente como:
primero consultamos qué productos cambiaron y después enviamos actualizaciones sobre esos productos.
Ese nivel de comprensión suele ser suficiente para seguir la lógica funcional del proceso.
¿Qué es un endpoint?
Un endpoint es un punto específico dentro de una API al que podemos enviar una solicitud.
Una API puede tener diferentes endpoints para distintos recursos:
- productos;
- categorías;
- atributos;
- familias;
- imágenes;
- variantes.
Por eso podemos escuchar frases como:
«Tenemos que consultar el endpoint de categorías».
o:
«Ese campo no viene en el endpoint de producto».
La pregunta práctica detrás de ambas frases es la misma:
¿el sistema nos permite acceder al dato que necesitamos desde ese punto de la API?
¿Qué significan request, response y payload?
Estos términos suelen aparecer juntos.
Un request es la solicitud que un sistema envía a otro.
Un response es la respuesta que recibe.
El payload es el conjunto de datos que viaja dentro de un mensaje cuando corresponde.
Por ejemplo:
Request: actualizar el producto ABC123.
Payload: nombre, descripción, color, material y dimensiones.
Response: producto actualizado correctamente o mensaje de error.
Entonces, cuando alguien pregunta «¿qué viene en el payload?», la pregunta real es bastante simple:
¿qué información contiene el mensaje que estamos enviando o recibiendo?
¿Qué es JSON?
JSON (JavaScript Object Notation) es un formato de texto utilizado para intercambiar datos estructurados.
Un ejemplo simplificado puede verse así:
{
“sku”: “ABC123”,
“nombre”: “Silla de comedor”,
“color”: “Verde”,
“material”: “Madera”
}
No necesitamos aprender a programar JSON para trabajar con un catálogo.
Lo importante es reconocer que, cuando vemos una estructura así, estamos mirando información organizada en campos y valores.
Y ahí los perfiles de producto podemos aportar muchísimo:
¿El SKU es correcto? ¿El nombre corresponde? ¿El color utiliza el vocabulario aprobado? ¿Falta algún atributo? ¿La variante tiene su propio identificador?
El formato puede ser técnico; el significado de los datos sigue siendo una decisión del negocio.
El equipo técnico puede definir cómo viaja el dato. El equipo de producto tiene que poder decir si el dato que viaja es el correcto.
¿Qué es un conector?
Un conector es una solución diseñada para comunicar dos aplicaciones concretas.
Por ejemplo, podemos tener un conector entre un PIM y Shopify, entre un PIM y un DAM o entre un PIM y un marketplace.
Normalmente, el conector utiliza las capacidades de integración de ambos sistemas y agrega parte de la lógica necesaria para que puedan trabajar juntos.
Esto puede incluir:
- autenticación;
- consulta y envío de productos;
- mapeo de campos;
- transformaciones;
- reglas de sincronización;
- gestión de errores.
Por eso, saber que existe «un conector con Shopify» no alcanza para decidir si resuelve nuestro proyecto.
También necesitamos preguntar:
¿Qué información sincroniza? ¿En qué dirección? ¿Qué podemos configurar? ¿Qué entidades soporta? ¿Qué sucede con nuestros campos personalizados? ¿Cómo reporta los errores?
Un conector puede ahorrar mucho desarrollo, pero eso no significa que contemple automáticamente todas las particularidades de nuestro catálogo.
¿Qué es middleware?
El middleware es una capa intermedia que ayuda a coordinar la comunicación entre sistemas.
Puede recibir datos, validarlos, transformarlos, combinar información de diferentes fuentes y enviarlos al destino correspondiente.
Volviendo al ejemplo:
ERP → middleware → PIM → middleware → eCommerce
No significa que siempre necesitemos esa arquitectura. Sirve para visualizar que, en algunos proyectos, la información no viaja directamente de una aplicación a otra.
Yo lo comparo bastante con una etapa de preproducción editorial. El manuscrito que entrega un autor no siempre es exactamente el archivo que necesita recibir una imprenta. Entre ambos existen controles, correcciones, ajustes y conversiones que preparan el material para su destino.
Con los datos puede pasar algo parecido.
El middleware no tiene por qué convertirse en otra fuente de verdad. Su función puede ser simplemente conseguir que dos sistemas con estructuras diferentes puedan entenderse.
¿Qué es un iPaaS?
iPaaS significa Integration Platform as a Service.
Es una plataforma desde la que se pueden construir, ejecutar y monitorear integraciones entre diferentes aplicaciones.
La diferencia que me resulta más útil para recordarlo es esta:
Middleware describe una capa o función intermedia.
iPaaS describe una plataforma que puede utilizarse para construir y gestionar ese tipo de flujos.
Son conceptos relacionados, pero no son exactamente sinónimos.
¿Qué es un webhook?
Un webhook permite que un sistema avise a otro cuando ocurre un evento.
Por ejemplo:
«Se creó un producto».
«Se actualizó una imagen».
«Cambió el estado de una publicación».
El sistema que detecta el evento envía una notificación al sistema que necesita reaccionar.
Podemos pensarlo como una alarma.
En lugar de revisar constantemente si apareció algo nuevo, esperamos a que el sistema nos avise.
¿Qué es polling y en qué se diferencia de un webhook?
Polling significa consultar periódicamente un sistema para comprobar si hubo cambios.
La lógica sería:
«¿Cambió algo?»
Cinco minutos después:
«¿Cambió algo?»
Después:
«¿Cambió algo?»
La diferencia básica es muy fácil de recordar:
Webhook: el sistema me avisa cuando sucede algo.
Polling: yo pregunto periódicamente si sucedió algo.
Uno no es automáticamente mejor que el otro. La decisión depende de las capacidades de los sistemas, la frecuencia requerida y la arquitectura de la integración.
¿Qué significan mapping y transformación?
El mapping o mapeo consiste en definir la correspondencia entre un campo de origen y uno de destino.
Por ejemplo:
product_name → Nombre
manufacturer → Marca
main_color → Color principal
Pero la correspondencia no siempre es directa.
Supongamos que el sistema de origen utiliza:
AZ
y el destino necesita:
Azul
Ahí tenemos que aplicar una transformación.
También necesitamos transformar cuando cambiamos unidades, separamos un campo en varios, unimos información o traducimos la estructura de una variante.
La diferencia puede resumirse así:
Mapear es definir dónde debe ir el dato. Transformar es definir cómo debe cambiar para llegar correctamente.
¿Qué son autenticación, token y permisos?
Una integración no debería permitir que cualquier sistema acceda libremente a toda la información.
La autenticación sirve para comprobar quién está intentando conectarse.
Un token funciona como una credencial que permite autorizar determinadas solicitudes.
Los permisos definen qué puede hacer esa conexión.
Por ejemplo, una integración puede tener permiso para consultar productos y actualizar descripciones, pero no para eliminar categorías.
Desde un perfil de contenido probablemente no tengamos que configurar esas credenciales, pero sí conviene entender el principio:
una integración debería tener acceso solamente a aquello que necesita para cumplir su función.
¿Qué significan batch, delta y sincronización?
Estos términos describen diferentes maneras de procesar información.
Un proceso batch trabaja con un conjunto de registros en bloque. Por ejemplo, todos los productos pendientes de actualizar durante la noche.
Una actualización delta procesa únicamente aquellos registros que cambiaron desde la última ejecución.
Una sincronización busca mantener determinados datos coherentes entre sistemas según las reglas definidas.
También tenemos que entender la dirección del flujo:
Unidireccional: A → B
Bidireccional: A ↔ B
Esta diferencia es importante porque una integración que publica datos desde el PIM hacia el eCommerce no implica automáticamente que los cambios realizados en el eCommerce regresen al PIM.
¿Qué son los logs y para qué sirve el monitoreo?
Un log es un registro de lo que ocurrió durante la ejecución de un proceso.
Puede indicar:
- qué producto se procesó;
- cuándo;
- qué acción se intentó;
- cuál fue el resultado;
- qué error apareció.
El monitoreo utiliza esa información para observar el funcionamiento de la integración y detectar problemas.
Para quienes trabajamos con catálogo, esto tiene una consecuencia muy concreta.
«La integración falló» no alcanza.
Necesitamos poder llegar a algo como:
Producto: ABC123
Proceso: actualización
Resultado: error
Campo: categoría
Motivo: valor no reconocido
Ese nivel de información permite convertir un error técnico en una tarea que el equipo puede diagnosticar y resolver.
Un buen mensaje de error debería ayudarnos a identificar qué producto falló, qué dato provocó el problema y en qué parte del flujo ocurrió.
Un caso real: cuando detrás de una flecha hay varios procesos
En un proyecto real para un fabricante B2B del sector de materiales de construcción, el ecosistema incluía un ERP, un PIM y una plataforma de comercio B2B.
El alta inicial de productos llegaba desde el ERP mediante un archivo CSV. Esa información requería algunas transformaciones antes de ingresar al PIM.
Después, para llevar los productos enriquecidos desde el PIM hacia la plataforma comercial, se desarrolló un conjunto de scripts acompañado por un orquestador. También se implementó un panel para monitorear el resultado de la integración.
En un diagrama rápido podríamos resumirlo así:
ERP → PIM → eCommerce
Pero esas dos flechas representaban formatos de intercambio, transformaciones, mapeos, ejecuciones programadas, control de errores y monitoreo.
Ese es uno de los motivos por los que este vocabulario importa. Una integración no es una línea abstracta entre dos cajas: es una secuencia concreta de decisiones sobre cómo se mueve la información.
¿Qué preguntas debería poder hacer un perfil no técnico?
No necesitamos preguntar cómo está escrito el código.
Podemos hacer preguntas mucho más útiles para nuestro rol:
- ¿Cuál es el sistema de origen de este dato?
- ¿En qué dirección viaja?
- ¿Qué campos se están mapeando?
- ¿Hay alguna transformación entre origen y destino?
- ¿Con qué frecuencia se ejecuta el proceso?
- ¿Qué dispara la actualización?
- ¿Qué ocurre si un producto da error?
- ¿Dónde podemos consultar el resultado de la ejecución?
- ¿Cómo validamos que la información llegó correctamente?
- ¿En qué sistema debería corregirse un dato incorrecto?
Con estas preguntas ya podemos participar activamente desde producto, contenido o negocio.
Y, además, podemos detectar algo que aparece con bastante frecuencia: problemas que llegan a la conversación como “errores de integración” pero cuyo origen real está en el dato, en el mapeo o en una regla que nunca se definió.
Glosario rápido de integraciones PIM
| Término | Definición breve |
|---|---|
| API | Interfaz que permite que dos aplicaciones se comuniquen |
| REST API | Forma habitual de exponer recursos y operaciones mediante HTTP |
| Endpoint | Punto específico de una API |
| Request | Solicitud enviada a un sistema |
| Response | Respuesta que devuelve el sistema |
| Payload | Datos incluidos dentro de un mensaje |
| JSON | Formato de texto estructurado para intercambiar datos |
| Conector | Solución preparada para comunicar sistemas concretos |
| Middleware | Capa intermedia que coordina o transforma información |
| iPaaS | Plataforma para construir y operar integraciones |
| Webhook | Notificación automática disparada por un evento |
| Polling | Consulta periódica para comprobar si hubo cambios |
| Mapping | Correspondencia entre campos de origen y destino |
| Transformación | Modificación aplicada a un dato antes de enviarlo |
| Token | Credencial utilizada para autorizar solicitudes |
| Batch | Procesamiento de varios registros en conjunto |
| Delta | Procesamiento limitado a los registros que cambiaron |
| Log | Registro de lo ocurrido durante una ejecución |
| Monitoreo | Seguimiento del funcionamiento de la integración |
Cuando empezamos a trabajar con integraciones, la cantidad de términos técnicos puede hacernos pensar que la conversación pertenece exclusivamente al equipo de desarrollo. En realidad, detrás de API, webhook, mapping o middleware siempre aparecen preguntas muy concretas sobre nuestros productos: qué dato sale, cuál llega, cómo cambia y quién es responsable de mantenerlo. Entender ese vocabulario no nos convierte en programadores, pero sí nos permite participar mejor en las decisiones que determinan si la información del catálogo llega correctamente a cada sistema.
