Puente OS vs middleware a medida: diferencias y cuándo conviene

Un middleware a medida es software construido para tu empresa que se ubica entre dos o más sistemas y traduce, mueve y sincroniza datos entre ellos: las órdenes del marketplace hacia tu ERP, el stock del ERP hacia tu tienda, el pedido hacia tu WMS o la venta hacia tu facturador. Puente OS es la plataforma que construye los sistemas que operan tu negocio: apps, workflows, bases de datos y agentes que leen de tus sistemas, cruzan la información que ninguno tiene completa, deciden con tus reglas y ejecutan la acción dentro de ellos. El middleware lleva el dato de un sistema a otro, y Puente OS conecta tus sistemas y opera el trabajo que ese dato pone en marcha.

Soy Cris Ugarte, CEO y cofundador de Puente OS. Trabajamos con empresas de retail, eCommerce y logística en Chile, Perú y México, y en muchas de ellas ya corren integraciones construidas a medida: un script que baja las órdenes del marketplace, un conector entre la tienda y el ERP o un proceso nocturno que sube el stock. La pregunta que aparece es concreta: ¿conviene construir la siguiente integración a medida o hacerla con Puente?

Mi respuesta parte por mirar la vida completa de una integración. Construirla es la primera etapa, y después viene mantenerla viva mientras cambian las APIs, las credenciales, las reglas y las personas. Acá reviso qué resuelve cada camino, con fuentes públicas para todo lo que digo de la industria y de las plataformas, y en qué casos conviene cada uno.

¿Qué es un middleware a medida y qué resuelve?

Un middleware a medida resuelve una conexión puntual con exactitud: el código hace lo que tu sistema necesita, con tus campos, tus excepciones y tu forma de trabajar, y queda bajo tu control. Lo construye tu propio equipo de desarrollo, un freelancer o una software factory, y suele tomar una de estas formas:

Un conector entre tu eCommerce o tus marketplaces y tu ERP, que lleva las órdenes al ERP y devuelve el stock y los precios a cada canal.
Una sincronización con tu WMS o tu operador logístico, que manda los pedidos a preparar y trae los estados de despacho.
Una conexión con tu facturador, que emite el documento tributario de cada venta.
Un proceso programado que lee archivos, como una planilla o un FTP, y los carga en otro sistema.

Sus fortalezas son reales:

Control total. El código, la lógica y el lugar donde corre los decide tu empresa.
Encaje exacto. Se adapta a un ERP muy personalizado, a un sistema propio o a un formato que ninguna herramienta trae resuelto.
Alcance abierto. Cualquier sistema que tenga una API, una base de datos o un archivo legible se puede conectar.

Construir uno toma semanas. Una agencia digital que construye integraciones entre eCommerce y ERP estima, en octubre de 2026, para el mercado de Ámsterdam, entre 6 y 12 semanas por conector según el ERP: 2 semanas de mapeo de datos, 3 a 6 de desarrollo y 2 a 4 de pruebas en un ambiente de staging. Un proveedor de conectores para eCommerce describe cuatro fases para integrar Shopify con un ERP (mapeo de flujos, construcción, pruebas y capacitación, lanzamiento y estabilización) y dice que la mayoría de estos proyectos toma de 8 a 16 semanas.

En la misma estimación, la agencia marca hasta dónde basta un conector a medida: entre 2 y 4 flujos de datos. Sobre 5 flujos, o con varios ERP, recomienda una plataforma de integración (iPaaS).

Una conexión exacta, hecha a la medida de tu sistema y bajo tu control: ese es el trabajo del middleware a medida.

¿Qué es Puente OS y qué resuelve?

Puente OS es la plataforma que construye los sistemas que operan tu negocio. En tu stack es el system of action: lee de tus sistemas, cruza la información que ninguno tiene completa, decide con tus reglas y ejecuta la acción dentro de ellos, escribiendo de vuelta.

Lo que construye sale de cuatro piezas:

Bases de datos que juntan el contexto de varios sistemas: la orden del marketplace, su documento, su despacho y su pago en un mismo registro.
Workflows que conectan tus sistemas y aplican reglas explícitas y auditables. Parten solos a una hora fija o cuando otro sistema les avisa por webhook que algo cambió.
Agentes para los tramos que requieren criterio, como un reclamo ambiguo o una diferencia que hay que investigar.
Apps donde tu equipo ve, decide y aprueba las excepciones.

Las conexiones se arman con lo que ofrece cada sistema. Puente trae conectores nativos para WooCommerce, Multivende, Mercado Libre y Bsale, entre otros: con Multivende actualiza el stock en bloque, con Mercado Libre lee órdenes y el detalle de cada envío, y con Bsale, stock y documentos. Para el resto, y para escribir de vuelta en esos mismos sistemas, un workflow llama a la API por HTTP o con Python, recibe los eventos por webhook o lee la base de datos del ERP cuando ese es el acceso disponible. En producción, por ejemplo, Puente se conecta a SAP Business One con un workflow en Python que lee su base de datos cada día.

Con Puente OS describes en lenguaje natural lo que tu operación necesita y obtienes software corriendo: apps, workflows, bases de datos y agentes. El equipo de Growth Ops de Puente construye cada proceso contigo y lo mantiene, y cada uno llega a producción en 2 a 4 semanas. Puente actúa sobre tus sistemas, y donde la operación vive en planillas, también guarda el registro.

La disciplina detrás es el Diseño Autónomo: diseñar tu operación para que lo repetible corra solo, con tus reglas, y tu equipo decida lo que requiere criterio. Una de sus condiciones es la que persigue toda integración: tus sistemas se hablan solos. El detalle de la capa está en qué es un system of action.

¿Qué pasa con una integración después de que sale a producción?

Empieza la etapa más larga de su vida. Las APIs de las que depende cambian, las credenciales vencen, las plataformas suben sus exigencias y la operación pide reglas nuevas. Una integración en producción necesita a alguien que la adapte de forma continua y que entienda cómo funciona. Una agencia de integraciones lo dice directo: tarde o temprano una sincronización falla, por un ítem borrado en el ERP, un cliente sin cuenta, una caída de red o una actualización de versión, y por eso recomienda probar cada actualización en un ambiente conectado a una copia del ERP.

Las plataformas actualizan sus APIs con su propio calendario:

Shopify publica una versión nueva de su API cada tres meses, el primer día de cada trimestre, y soporta cada versión estable por al menos 12 meses. Cuando una versión se retira, las llamadas pasan a la versión soportada más antigua. Su REST Admin API pasó a ser una API legada el 1 de octubre de 2024, y desde el 1 de abril de 2025 toda app pública nueva se construye solo con la GraphQL Admin API.
VTEX anunció el 23 de mayo de 2025 que su API legacy Webservice quedaba discontinuada el 1 de septiembre de ese año, y las tiendas que la usaban tuvieron que migrar a sus APIs REST. En 2023 ya había deprecado un endpoint de checkout que las integraciones debían reemplazar por los de su OMS.
Bsale publica un changelog de su API: en 2025 registró cambios en 11 de los 12 meses, y en octubre de ese año bajó su límite de 10 a 8 solicitudes por segundo. Varias de sus entradas son validaciones nuevas, como una sobre valores negativos en el campo netUnitValue, de enero de 2026.
Falabella exige en cada solicitud a la API de su Seller Center un encabezado User-Agent con un formato definido (vendedor, tecnología, versión, tipo de integración y país), y su flujo de stock en varias bodegas pide la versión 2.0 de GetOrders y GetOrder.
Defontana recomienda, en la documentación de su API, contar con un equipo de desarrollo que implemente y mantenga la integración, porque ese desarrollo es «responsabilidad del cliente o de su proveedor tecnológico». Cada token nuevo invalida al instante todos los anteriores del mismo usuario, y su ambiente de pruebas se reescribe cada semana con datos de producción y no opera los fines de semana.
SAP Business One recomienda en SAP Learning reiniciar los servicios del Service Layer al menos una vez al día y programar las operaciones masivas en horas de baja concurrencia. Sana Commerce, un proveedor de eCommerce para SAP, informa que el DI Server, otra vía de integración de SAP Business One, está en soporte pasivo, y su guía de migración al Service Layer advierte que, al migrar, algunas funciones de su propia plataforma dejan de funcionar porque los nombres de los campos difieren entre ambos, y hay que volver a configurarlas.

Las credenciales y las reglas de acceso piden atención permanente:

En Mercado Libre, el access token vence a las 6 horas y el refresh token es de un solo uso: cada renovación entrega uno nuevo y solo vale el último. El token también se invalida antes de tiempo si el usuario cambia su contraseña, si la app actualiza su Client Secret, si el usuario revoca los permisos o si la app pasa 4 meses sin llamar a la API.
Mercado Libre publica su plan de Seguridad en Integraciones, actualizado el 4 de marzo de 2026, como el estándar que exige a los integradores: rotación de secretos, MFA obligatorio, autenticación en todos los endpoints, rate limiting, cifrado de datos personales, validación de webhooks con HMAC-SHA256, monitoreo de anomalías y un proceso listo para revocar tokens en masa, entre otros requisitos.
Mercado Libre también puede bloquear una aplicación por incumplir su validación de datos o sus términos, por exceso de llamadas o mal uso del token, o por infracciones con los datos, y un exceso de errores 4xx no previstos puede causar el bloqueo. Una app bloqueada queda fuera de todas las APIs de Mercado Libre y Mercado Pago, y sus vendedores tienen que operar a mano desde el sitio.

Lo que viene después del lanzamiento es la mayor parte del trabajo. Los proveedores de infraestructura de integraciones lo describen con detalle. Ampersand, que construye infraestructura de integraciones para empresas SaaS, estima que en las integraciones que esas empresas entregan a sus clientes la construcción visible es cerca del 30% del trabajo de toda su vida, y que la mayoría de los equipos lo subestima por un factor de dos o tres. Lo que sigue: migraciones de versión de API, cambios de esquema, refresco de tokens, límites de solicitudes, reintentos de webhooks y comportamientos que nadie documentó. OpusGo, otro proveedor, agrega que el código punto a punto se rompe con los parches del ERP.

Y la continuidad depende de cuánto de lo que se sabe queda escrito fuera de la cabeza de quien la construyó. La investigación lo mide con el bus factor, o truck factor: el número mínimo de desarrolladores que tendrían que irse para que un proyecto quede detenido. En 133 proyectos populares de GitHub, un estudio presentado en ICPC 2016 encontró que el 65% tiene un truck factor de 2 o menos. Son proyectos de código abierto, y en la industria el diagnóstico se repite: en una encuesta a 269 ingenieros, hecha con JetBrains, el bus factor aparece como un problema importante del desarrollo en equipo.

La documentación es la otra mitad. En la encuesta Open Source de GitHub de 2017, el 93% de los encuestados había encontrado documentación incompleta o desactualizada.

Esos cambios le llegan a cualquier integración, la que construye Puente incluida. Lo que define cuánto pesan en tu operación es quién adapta la conexión, en cuánto tiempo se entera de que algo cambió y cuánto de lo que sabe queda escrito. Cuando una integración se detiene, tu equipo vuelve a mover los datos a mano, y ese trabajo tiene nombre: el impuesto de coordinación.

¿En qué se diferencian Puente OS y un middleware a medida, dimensión por dimensión?

Un middleware a medida entrega la conexión que se especificó, y Puente OS entrega el proceso que la usa, con la conexión adentro y un equipo que la mantiene. Dimensión por dimensión:

Plazo. Middleware a medida: 6 a 12 semanas por conector según una agencia que estima el mercado de Ámsterdam, entre mapeo, desarrollo y pruebas, y de 8 a 16 según un proveedor de conectores. Puente OS: 2 a 4 semanas por proceso, con la conexión incluida.
Alcance. Middleware a medida: la conexión que se especificó en el proyecto, con sus reglas de traducción: qué campo va a cuál, cada cuánto corre y qué hace con un error. Puente OS: la conexión y el proceso que la usa, con la base de datos que cruza las fuentes, los workflows con tus reglas, la App donde tu equipo ve cada excepción y los agentes para los tramos con criterio.
Cambios de API. Middleware a medida: cada versión nueva, credencial que vence, límite de solicitudes o validación nueva se adapta en el código, a cargo de quien tenga el mantenimiento. Puente OS: el equipo de Growth Ops adapta la conexión cuando cambia una API, un canal, una regla o un formato, y los conectores de Mercado Libre y Multivende traen su propio paso para refrescar el token. La versión nueva de un workflow hereda el mismo webhook y el mismo horario, así que tus sistemas siguen llamando al mismo lugar.
Monitoreo y fallas. Middleware a medida: los registros, las alertas y los reintentos que el proyecto incluya. Puente OS: cada ejecución guarda su estado, el paso donde se detuvo y, por paso, el error y su registro, y las alertas de falla traen un extracto del error. Cada paso define si una falla detiene el proceso o lo deja seguir, y los procesos que escriben en otro sistema usan patrones como un chequeo de la conexión al empezar, una llave de idempotencia para no duplicar y una consulta del estado real antes de repetir un envío.
Historial y vuelta atrás. Middleware a medida: el control de versiones y el proceso de despliegue que defina el equipo que lo mantiene. Puente OS: cada guardado de un workflow crea una versión, con autor y fecha, y volver atrás es activar la anterior. Cada publicación de una app también queda como versión en su historial. Antes de una acción irreversible, el workflow puede dejar un borrador que tu equipo confirma.
Quién lo mantiene. Middleware a medida: tu equipo de desarrollo, el freelancer o la software factory que lo construyó, según lo que acuerden. Puente OS: el equipo de Growth Ops que lo construyó contigo, que lo mantiene a medida que tu operación crece.
Documentación. Middleware a medida: la que tu equipo escriba y mantenga junto al código. Puente OS: las reglas quedan escritas en explícito en cada workflow, y el historial de versiones y de ejecuciones muestra qué cambió, cuándo y qué corrió en cada paso.
Permisos y auditoría. Middleware a medida: los que se diseñen en el proyecto, sobre la infraestructura donde corre. Puente OS: cada app recibe permisos explícitos por tabla (leer, escribir o borrar), con mínimo privilegio, y las tablas y conexiones pertenecen a tu equipo en la plataforma. Las columnas con datos sensibles se pueden cifrar: solo un workflow de tu mismo equipo lee el valor real, y cada lectura deja un evento de auditoría con sus metadatos, con el valor fuera de los logs.
Crecer a otro proceso. Middleware a medida: cada conector nuevo pasa por su propio mapeo, desarrollo y pruebas. Puente OS: el siguiente proceso se suma sobre las mismas conexiones y los mismos datos, y llega más rápido que el primero (ver el Ejemplo 3).
Cómo se construye. Middleware a medida: se escribe en código, a cargo de quien lo desarrolla. Puente OS: describes en lenguaje natural lo que tu operación necesita y obtienes software corriendo; en la operación, un modelo lee lo que llega desordenado y un agente toma los tramos con criterio, mientras la lógica crítica corre con reglas explícitas y auditables.

¿Cómo se ve en una operación real?

Se ve como integraciones que viven dentro de procesos completos, con una persona que las construye sobre la plataforma y un equipo que las mantiene. Tres clientes de Puente OS:

Ejemplo 1: siete canales y 19 APIs en un vendedor multicanal de electrónica en México

Un vendedor de electrónica en México opera sin ERP, y Puente tiene conectados siete de sus canales de venta, con 19 APIs en total. Cada orden que Puente despacha sigue su camino con reglas: la dirección se valida, la paquetería se elige con reglas por zona, tipo de envío y seguro, la guía se genera y el número de seguimiento queda escrito en la orden. Puente también consolida por API 213.362 órdenes de Mercado Libre en un solo reporte de ventas.

Entre noviembre de 2025 y agosto de 2026, Puente procesó de punta a punta 38.628 órdenes, y el 97,9% salió con su guía sin intervención humana: 37.815 guías. Generar las guías de un corte pasó de 5 a 7 horas a 15 minutos, y el volumen mensual creció 40% con el mismo equipo de operaciones. Entre el 1 y el 12 de agosto, 12 de 2.051 órdenes tuvieron una incidencia, el 0,59%, con una mediana de resolución de 10 minutos. Detrás hay 20 apps y 75 procesos, construidos en diez meses por una persona de Puente sobre la plataforma: las reglas, las versiones y cada ejecución quedan a la vista del equipo.

Ejemplo 2: dos canales en un CRM y un catálogo por FTP en un retailer chileno

Un retailer chileno vende en su tienda física y en su tienda online. Puente consolidó las órdenes de los dos canales en un CRM único: 27.656 órdenes entre diciembre de 2025 y agosto de 2026, con 9.686 clientes identificados. Su catálogo llega por FTP y se refresca tres veces al día, en una corrida de unos cinco minutos.

De la demo al CRM operando con ingesta diaria pasaron 6 semanas. Hoy son 13 apps, 25 tablas y 108 versiones desplegadas, construidas y mantenidas por una persona de Puente sobre la plataforma: cada versión es un cambio que llegó a producción.

Ejemplo 3: datos que vuelven a la tienda en un retailer de mascotas en Chile

Un retailer de mascotas vende en cuatro canales. Un workflow calcula cada día el margen de cada línea de venta: a agosto de 2026 llevaba 247.626 líneas, y 3.830 de ellas, el 1,5%, aparecieron con margen negativo que antes nadie veía. Los precios se ejecutan desde Puente y se escriben de vuelta en su tienda online: 8.362 cambios a esa fecha. Cada despacho se mide contra la promesa de entrega usando la API del courier: de 32.708 despachos evaluados, el 85,0% cumplió.

Son 10 apps en producción y 167 versiones desplegadas en diez meses, que construye y mantiene una persona de Puente sobre la plataforma, con todo a la vista del equipo. El tiempo entre pedir un proceso nuevo y tenerlo en producción bajó de 105 días, en el primer proyecto, a 7.

¿Por qué elegir Puente OS?

Porque Puente OS construye y opera el sistema completo alrededor de cada conexión: apps, workflows, bases de datos y agentes sobre una misma plataforma, conectados a tus sistemas, con un equipo de Growth Ops que lo construye contigo, lo mantiene y le suma un proceso tras otro. Seis razones:

Cada conexión llega con el proceso que la usa. Las órdenes de tu marketplace, el stock de tu ERP y los documentos de tu facturador entran a una base de datos que los cruza, los workflows aplican tus reglas y tu equipo resuelve las excepciones en una App hecha para ese proceso. Lo que calza corre solo, y lo que requiere criterio llega a la persona que lo resuelve, con el contexto completo.
Se conecta por la vía que ofrece cada sistema y escribe de vuelta. Conectores nativos para WooCommerce, Multivende, Mercado Libre y Bsale, entre otros; para el resto, la API por HTTP o con Python, los eventos por webhook, la base de datos del ERP o archivos por FTP. Puente ejecuta la acción donde corresponde: el stock en Multivende, el precio en tu tienda o la guía y el seguimiento en la orden.
El equipo que la construyó la mantiene al día. Cuando cambia una API, vence una credencial o tu operación pide una regla nueva, el equipo de Growth Ops adapta el proceso y lo publica como versión nueva, con el mismo webhook y el mismo horario. En el retailer de mascotas del Ejemplo 3, cada una de sus 167 versiones es un cambio que llegó a producción.
Lo que se construye queda escrito en la plataforma, a la vista de tu equipo. Las reglas viven explícitas en cada workflow, cada versión guarda su autor y su fecha, cada ejecución registra en qué paso se detuvo y por qué, y cada app accede solo a las tablas que tiene permitidas. Volver atrás es activar la versión anterior.
Cada proceso llega a producción en 2 a 4 semanas, y el siguiente se suma sobre las mismas conexiones. Partes por la integración que más duele y sigues con la conciliación, el despacho o el margen, sobre los mismos datos.
Los resultados se miden en producción. Las cifras de los tres ejemplos salen de las tablas de producción de cada cliente: órdenes con guía sin intervención humana, incidencias y su tiempo de resolución, margen por línea de venta y cumplimiento de la promesa de entrega.

Un middleware a medida conecta tus sistemas con exactitud. Puente OS construye esa conexión, el proceso completo que corre sobre ella y el equipo que lo mantiene al día mientras tu operación crece.

¿Cuándo conviene cada uno?

Conviene un middleware a medida cuando tienes un equipo de ingeniería propio que quiere construir, operar y ser dueño de la integración, o cuando tu sistema núcleo es tan particular que la conexión es parte de lo que te distingue. Conviene Puente OS cuando quieres el proceso completo funcionando y un equipo que lo mantenga conectado mientras tus sistemas cambian.

Middleware a medida, si tienes ingenieros con tiempo para mantenerlo, un ERP o sistema propio muy personalizado, una política que exige que el código corra en tu infraestructura o una conexión acotada: una agencia de integraciones estima que un conector a medida basta para 2 a 4 flujos. Es la opción que te da control total del código y de su hoja de ruta.
Puente OS, si tu equipo mueve datos a mano entre sistemas, si tus integraciones tienen reglas que nadie dejó por escrito o se detienen seguido, o si la conexión es el primer paso de un proceso que quieres que corra solo: la conciliación, el despacho, el margen o la facturación. También si quieres sumar procesos sobre las mismas conexiones, con un equipo que los construye contigo y los mantiene.
Los dos, cuando ya tienes una integración a medida que funciona y tiene quien la mantenga. Puente lee de los sistemas que esa integración sincroniza, por su API o su base de datos, y construye encima el proceso siguiente.

¿Cómo partir?

Por un proceso acotado que duela, con volumen y traspasos manuales. El riesgo de un proyecto de software crece con su tamaño. El CHAOS Report 2015 del Standish Group, sobre más de 25.000 proyectos de software, encontró que el 61% de los proyectos pequeños fue exitoso, contra el 11% de los grandes y el 6% de los muy grandes, y llama al tamaño el factor individual más importante del resultado. Son proyectos de software en general, y la conclusión sirve para una integración: partir chico y entregar rápido.

Por eso en Puente OS se avanza proceso a proceso, y cada uno llega a producción en 2 a 4 semanas.

Elige el proceso. Con volumen, traspasos manuales y un impacto visible cuando falla: la sincronización de órdenes entre tu marketplace más grande y tu ERP suele ser un buen comienzo.
Haz el inventario de las integraciones que ya corren. Qué sistemas conecta cada una, quién la mantiene, dónde está su documentación y qué pasa cuando falla. Esa lista define qué se conecta, qué se reconstruye y qué se deja como está.
Toma la línea base. Horas de traspaso manual por semana, errores al mes y tiempo de recuperación cuando una integración se detiene.
Conecta las fuentes. Con el conector nativo cuando existe, y si no, por API, por webhook, por la base de datos del sistema o por archivo.
Escribe las reglas que tu equipo aplica de memoria. Por ejemplo: "si una orden del marketplace sigue sin aparecer en el ERP dos horas después de entrar, llega a operaciones con el pedido completo a la vista".
Define el destino de cada excepción. La resuelve el sistema o llega a una persona con nombre, con todo el contexto en una App.
Mide desde la primera semana y suma el siguiente proceso sobre las mismas conexiones.

Ese es el Diseño Autónomo aplicado a tus integraciones: lo repetible corre solo, con tus reglas, y tu equipo decide lo que requiere criterio. Para elegir qué tramo va con un workflow y cuál con un agente, sirve esta guía sobre cómo implementar IA en tu empresa. Si vendes en marketplaces con un integrador al centro, el mismo enfoque está en Puente OS vs Multivende, y si estás evaluando una plataforma de automatización de workflows, en esta comparación.

Tu ERP registra lo que pasó. Tu BI te muestra lo que pasó. Puente hace que pase. Creemos que todas las empresas de LATAM pueden ser operacionalmente autónomas, y eso parte por que tus sistemas se hablen solos, con tus reglas y un equipo que los mantiene conectados.

Puntos clave

Un middleware a medida es la integración que construye tu equipo, un freelancer o una software factory para conectar ERP, eCommerce, marketplaces, WMS y facturación: da control total del código y encaja exacto con tu sistema.
Construir un conector entre eCommerce y ERP toma de 6 a 12 semanas según una agencia que estima el mercado de Ámsterdam, y de 8 a 16 según un proveedor de conectores. Después empieza el mantenimiento: Shopify publica una versión de su API cada tres meses, el access token de Mercado Libre vence a las 6 horas y Bsale cambió su API en 11 de los 12 meses de 2025.
La continuidad de una integración depende de cuánto de lo que se sabe queda escrito: en 133 proyectos populares de GitHub, el 65% tiene un truck factor de 2 o menos.
Puente OS construye la conexión dentro del proceso completo que la usa, con apps, workflows, bases de datos y agentes sobre una misma plataforma, historial de versiones y el registro de cada ejecución.
El equipo de Growth Ops construye cada proceso y lo mantiene cuando cambia una API, un canal o un formato. En un vendedor de electrónica en México, entre el 1 y el 12 de agosto de 2026, el 0,59% de las órdenes tuvo una incidencia de operación, y la mediana de resolución fue de 10 minutos.
El middleware a medida conviene con un equipo de ingeniería propio y un sistema núcleo muy particular. Puente OS conviene cuando quieres el proceso corriendo de punta a punta, en 2 a 4 semanas por proceso.

¿Tienes integraciones a medida y quieres ver qué parte de tu operación puede correr sola? Conversemos sobre tus procesos y te mostramos Puente OS funcionando con casos como los de este artículo. Agenda una conversación con nuestro equipo.

Preguntas frecuentes

¿Qué es un middleware?

Un middleware es software que se ubica entre dos o más sistemas y les permite intercambiar datos: traduce formatos, mueve registros de un sistema a otro y mantiene la información sincronizada. En una operación de retail o eCommerce, conecta el ERP con la tienda online, los marketplaces, el WMS, el courier y el facturador. Puede construirse a medida, con desarrollo propio, un freelancer o una software factory, o armarse sobre una plataforma de integración (iPaaS). Puente OS construye esas conexiones como parte del proceso completo que las usa, con apps, workflows, bases de datos y agentes.

¿Cuánto se demora una integración entre un ERP y un eCommerce?

Una agencia que construye estos conectores estima, para el mercado de Ámsterdam, entre 6 y 12 semanas: 2 semanas de mapeo de datos, 3 a 6 de desarrollo y 2 a 4 de pruebas. Según el ERP, calcula 6 a 8 semanas para Odoo 17 o 18, 8 a 10 para Sage 100 o 200 y 10 a 12 para Sage X3. Un proveedor de conectores dice que la mayoría de las integraciones entre Shopify y un ERP toma de 8 a 16 semanas. Son cifras de Europa y Estados Unidos. Con Puente OS, cada proceso llega a producción en 2 a 4 semanas, con la conexión incluida.

¿Qué pasa si cambia la API de mi ERP o de mi marketplace?

La integración tiene que adaptarse, y esos cambios son frecuentes: Shopify publica una versión nueva de su API cada tres meses, VTEX discontinuó su API legacy Webservice en 2025, Bsale registró cambios en su API en 11 de los 12 meses de 2025 y el access token de Mercado Libre vence cada 6 horas. En una integración a medida, el ajuste lo hace quien tenga el mantenimiento. En Puente OS, el historial de ejecuciones muestra en qué paso se detuvo un proceso y por qué, las alertas de falla traen un extracto del error y el equipo de Growth Ops adapta la conexión. La versión nueva del workflow hereda el mismo webhook y el mismo horario, y si algo no anda, volver atrás es activar la versión anterior.

¿Puente OS reemplaza mi integración actual?

Puede tomarla o convivir con ella. Si tu integración funciona y tiene quien la mantenga, Puente lee de los sistemas que ella sincroniza y construye encima el proceso siguiente. Si su lógica no está documentada o se detiene seguido, el equipo de Growth Ops puede reconstruir esa conexión dentro de Puente OS, con su historial de versiones, el registro de cada ejecución y un equipo que la mantiene. La decisión se toma al levantar el proceso, con el inventario de lo que ya corre: qué conecta cada integración, quién la mantiene y qué pasa cuando falla.

¿Puente OS se conecta con mi ERP?

Sí, por la vía que tu ERP ofrece. Puente OS trae conectores nativos para sistemas como WooCommerce, Multivende, Mercado Libre y Bsale. Con el resto, el equipo de Growth Ops conecta con un workflow que llama a la API por HTTP o con Python, recibe sus eventos por webhook, lee su base de datos cuando el ERP da ese acceso o toma sus archivos. Con SAP Business One, por ejemplo, Puente lee en producción la base de datos del ERP con un workflow en Python que corre cada día. Qué vía corresponde depende del acceso que entregue tu ERP, y se define al levantar el proceso.

¿Qué es el bus factor de una integración?

El bus factor, también llamado truck factor, es el número mínimo de personas que tendrían que salir de un proyecto para que se detenga. En 133 proyectos populares de GitHub, un estudio de 2016 encontró que el 65% tiene un truck factor de 2 o menos. En una integración, mide cuántas personas entienden cómo funciona, y sube con documentación al día, reglas escritas en explícito y más de una persona que conozca el sistema. En Puente OS, lo que se construye queda en la plataforma: las reglas escritas en cada workflow, el historial de versiones y el registro de cada ejecución, con el equipo de Growth Ops a cargo de mantenerlo. Por eso en Puente una persona construye y mantiene decenas de procesos: lo que sabe queda escrito en la plataforma, a la vista del equipo de Growth Ops.

Fuentes externas citadas

Las citas de fuentes en inglés son traducción nuestra. Todo lo que este post dice de la industria y de las plataformas sale de documentación oficial, estudios académicos o publicaciones de proveedores, revisados el 11 de octubre de 2026. Kolonell, Webgility, Ampersand, OpusGo y Sana Commerce venden integraciones, conectores o infraestructura para integraciones: sus estimaciones sirven como contexto de la industria, y de Kolonell citamos solo plazos y tipos de mantenimiento. Los estudios de bus factor y la encuesta de GitHub miden proyectos de código abierto, y las cifras de Standish hablan de proyectos de software en general. Las páginas de Mercado Libre fechan en formato día/mes. Las cifras de clientes de Puente OS son mediciones de producción de agosto de 2026; el tiempo de generación de guías y las fechas de pedido de cada proceso vienen del seguimiento con el cliente.

Plazos y mantenimiento de integraciones

Integración entre eCommerce y ERP en Ámsterdam, 2026 (blog de Kolonell, agencia digital con sede en Dakar, 5-oct-2026): 6 a 12 semanas por conector (2 de mapeo de datos, 3 a 6 de desarrollo y 2 a 4 de pruebas en staging); por ERP, Odoo 17/18 de 6 a 8 semanas, Sage 100/200 de 8 a 10 y Sage X3 de 10 a 12; tarde o temprano una sincronización falla, y conviene un ambiente de prueba conectado a una copia del ERP antes de cada actualización; un conector a medida basta para 2 a 4 flujos, y sobre 5 flujos o con varios ERP se justifica un iPaaS. Estimación para el mercado de Ámsterdam.
Shopify ERP integration (Webgility, 29-dic-2025): cuatro fases (mapeo de flujos de datos, 2 a 3 semanas; construcción, 3 a 4; pruebas y capacitación, 3 a 6; lanzamiento y estabilización, 4 o más); la mayoría de los proyectos toma de 8 a 16 semanas, y la integración directa por API requiere mantenimiento continuo.
ERP, eCommerce and AI integration guide (OpusGo, 12-may-2026): el código punto a punto se rompe con los parches del ERP.
Integrations are 30% build, 70% everything after (Ampersand, 23-abr-2026): la construcción visible es cerca del 30% del trabajo de vida de una integración, y la mayoría de los equipos lo subestima 2 a 3 veces; después vienen las migraciones de versión de API, los cambios de esquema, el refresco de tokens, los límites de solicitudes, los reintentos de webhooks y el comportamiento no documentado. Contexto: integraciones que las empresas SaaS entregan a sus clientes en sistemas de registro; el autor aclara que no aplica a integraciones estables de solo lectura.

APIs de plataformas y ERP

API versioning (Shopify): una versión nueva cada tres meses, el primer día de cada trimestre; soporte mínimo de 12 meses por versión estable, con al menos 9 meses de traslape; las llamadas a una versión retirada pasan a la versión soportada más antigua.
REST Admin API reference (Shopify): la REST Admin API es legada desde el 1 de octubre de 2024, y desde el 1 de abril de 2025 toda app pública nueva se construye solo con la GraphQL Admin API.
Legacy Webservice API deprecation (VTEX Developers, release note del 23-may-2025): la API legacy Webservice se discontinúa el 1 de septiembre de 2025, y las tiendas deben migrar a las APIs REST.
Outdated checkout endpoint deprecation (VTEX Developers, release note del 16-ene-2023): el endpoint GET api/checkout/pub/orders queda deprecado desde el 25 de junio de 2023, y las integraciones deben migrar a los endpoints de OMS.
Changelog de la API de Bsale: el límite pasó a 10 solicitudes por segundo en 09/2023 y a 8 en 10/2025; entradas en 11 de los 12 meses de 2025 y en enero, marzo, abril, mayo, julio y agosto de 2026, como una validación de netUnitValue con valores negativos (01/2026).
Operate with APIs (Falabella Developers) y Manage multiwarehouse (Falabella Developers): toda solicitud lleva un encabezado User-Agent con el formato SELLER_ID/TECNOLOGÍA/VERSIÓN_TECNOLOGÍA/TIPO_INTEGRACIÓN/CÓDIGO_UNIDAD_DE_NEGOCIO y los parámetros Action, Timestamp, UserID, Version y Signature (HMAC-SHA256); el flujo de stock en varias bodegas exige la versión 2.0 de GetOrders y GetOrder. Las páginas no tienen fecha.
API REST de Integración (Centro de ayuda de Defontana, actualizada el 25 de agosto, sin año en la página): recomienda un equipo de desarrollo que implemente y mantenga la integración, que es «responsabilidad del cliente o de su proveedor tecnológico»; cada token nuevo invalida al instante los anteriores del mismo usuario; el ambiente de pruebas no está disponible sábado ni domingo y se reescribe cada semana con datos de producción.
Buenas prácticas de implementación y desarrollo con el Service Layer (SAP Learning): reiniciar los servicios Service Layer y SLD al menos una vez al día, reutilizar sesiones y programar las operaciones masivas en horas de baja concurrencia.
DI Server discontinued support (Sana Commerce, release notes de Sana for SAP Business One 1.0.56): según Sana, el DI Server está en soporte pasivo y SAP lo discontinuará; Sana dejó de soportar esa vía. Es fuente secundaria: no encontramos una nota oficial de SAP con fecha.
Migrating from DI Server to Service Layer (Sana Commerce): los nombres de campos difieren entre DI Server y Service Layer, y algunas funciones de la plataforma de Sana (Customer Assortment, filtros de la tienda, reglas de validación) deben volver a configurarse.
Autenticación y autorización (Mercado Libre Developers, actualizado el 15/07/2026): el access token vence a las 6 horas; el refresh token es de un solo uso y solo vale el último; el access token se invalida antes por un cambio de contraseña, una actualización del Client Secret, la revocación de permisos o 4 meses sin llamadas a la API.
Seguridad en Integraciones (Mercado Libre Developers, actualizado el 04/03/2026): el estándar que Mercado Libre exige a los integradores, con limpieza y rotación de secretos, MFA obligatorio, análisis de dependencias, autenticación en todos los endpoints, rate limiting, cifrado de datos personales, validación de webhooks con HMAC-SHA256, TLS 1.2 o superior, monitoreo de anomalías, RBAC y un proceso para revocar tokens en masa.
Bloqueo de aplicaciones (Mercado Libre Developers, actualizado el 15/04/2026): motivos NOT_COMPLY_KYC, NOT_COMPLY_T&C_RULES, EXCESSIVE_API_CALL (un exceso de errores 4xx no previstos puede causarlo) e INTEGRATORS_DATA_INFRACTION; una app bloqueada no opera con ninguna API de Mercado Libre ni de Mercado Pago, y sus vendedores operan a mano desde el sitio.

Documentación y proyectos de software

A Novel Approach for Estimating Truck Factors (Guilherme Avelino, Leonardo Passos, Andre Hora y Marco Tulio Valente, ICPC 2016): el truck factor es el número mínimo de desarrolladores que tendrían que irse para que un proyecto quede paralizado; en 133 proyectos populares de GitHub, el 65% tiene truck factor de 2 o menos. Proyectos de código abierto.
Bus Factor In Practice (Elgun Jabrayilzade, Mikhail Evtikhiev, Eray Tüzün y Vladimir Kovalenko, ICSE-SEIP 2022): en una encuesta a 269 ingenieros, el bus factor se percibe como un problema importante del desarrollo colectivo; el algoritmo se valida en 13 proyectos de JetBrains.
Open Source Survey 2017 (GitHub): el 93% de los encuestados observó documentación incompleta o desactualizada, y el 60% de los contribuidores rara vez o nunca aporta a la documentación. Muestra de 5.500 personas de más de 3.800 repositorios.
CHAOS Report 2015 (Standish Group, PDF): sobre más de 25.000 proyectos de software de FY2011-2015, éxito de 61% en los pequeños, 11% en los grandes y 6% en los muy grandes; el tamaño es el factor individual más importante del resultado, y la mayoría de los proyectos de software solo necesita un equipo chico por poco tiempo, mientras casi todos los proyectos grandes y de varios años son innecesarios, en especial en software de infraestructura estándar.

Puente OS vs middleware a medida: integrar tus sistemas y mantenerlos conectados