Un conector nativo en Odoo 19 conviene cuando Odoo manda sobre stock, pedidos, envíos y facturas: cada estado vive una sola vez, en la ficha donde trabaja el equipo. Un middleware conviene cuando solo hay que transportar datos sin tomar decisiones operativas, o cuando nadie va a mantener código dentro de Odoo. Conectar una API una vez nunca fue el problema: el problema es mantener pedidos, stock, errores y trazabilidad cuando la operación crece.
Idea clave: la pregunta no es «nativo» o «middleware», sino dónde vive cada estado y quién lo comprueba cuando no cuadra.
La diferencia real no está en la API
La API de Amazon, de Mirakl o de un transportista es la misma la llame quien la llame. Lo que cambia es quién guarda el resultado y dónde lo ve la persona que prepara el pedido: ahí está la diferencia, no en la API.
Si Odoo debe reservar stock, preparar pedidos, generar albaranes, crear etiquetas y devolver el tracking al canal, la integración nativa deja la trazabilidad donde trabaja el equipo. Con una capa intermedia, cada paso existe dos veces y las dos copias solo coinciden si alguien lo comprueba.
Cuándo elegir conector nativo en Odoo
Tiene sentido cuando Odoo es el sistema maestro de producto, stock, pedidos, logística y facturación. También cuando necesitas reglas propias: multi-almacén, validaciones antes de enviar, reintentos, registro de llamadas por pedido y errores que el usuario vea en su pantalla.
En nuestros conectores de marketplace, el registro de cada llamada es un modelo de Odoo con método, endpoint, parámetros, cuerpo enviado, código y cuerpo de respuesta, intento y duración en milisegundos, con purga configurable. Se filtra como cualquier lista de Odoo, sin depender de un panel externo.
Cuándo un middleware puede servir
Si solo mueves datos simples entre dos sistemas, sin decisiones operativas complejas, un middleware puede acelerar el arranque. También si varios ERP venden en los mismos canales y el stock publicado tiene que ser la suma. Y, sobre todo, si nadie, ni interno ni partner de Odoo, va a mantener código dentro del ERP.
El riesgo aparece cuando el equipo revisa tres paneles para saber si un pedido está vendido, reservado, enviado o fallido: ese día el middleware ha dejado de transportar y ha empezado a guardar estado.
Lo que cuesta un middleware en trabajo diario
La cuenta que importa no es la cuota mensual: son las tareas que aparecen en cuanto hay una capa intermedia y que nadie presupuesta. Son cuatro.
- El doble maestro. El producto se da de alta en Odoo y, además, se mapea en el middleware: SKU, categoría del canal, atributos obligatorios. Cada alta, cada cambio de EAN y cada variante nueva son dos ediciones. Con un conector nativo, el mapeo al canal es un campo más del producto en Odoo.
- La reconciliación de estados. Un pedido de marketplace tiene tres verdades: la del canal, la del middleware y la de Odoo. Cuando no coinciden —un pedido cancelado en el canal que en Odoo sigue reservando stock— alguien lo descubre a mano. Con conexión directa quedan dos, y el estado remoto se guarda tal cual lo devuelve la API junto al pedido de venta, con la hora de la última sincronización.
- Quién mira el log. El error de una llamada vive en el panel del proveedor, con su usuario y su retención. Quien ve el pedido atascado en Odoo no suele tener acceso a ese panel. Si el log es un modelo de Odoo, lo ve quien tiene el problema, en la misma pantalla.
- La subida de versión. Cuando Odoo pasa de 18 a 19, el middleware promete que su lado no cambia. El que sí cambia es el de Odoo: el módulo puente del proveedor, los campos que lee y los webhooks que espera. Esa migración la haces igualmente, al ritmo del proveedor y no al tuyo; publicamos para 19, 18 y 17 a la vez, como contamos en mantener un módulo en tres versiones.
Si ya pagas una capa intermedia y sospechas que te sobra, el plan de corte por canal está en del middleware a la conexión nativa en Odoo, contado desde nuestra propia migración de Amazon en producción.
Dónde se pierde la trazabilidad
El punto exacto es el albarán. En Odoo, el albarán (stock.picking) hereda de mail.thread y su estado tiene seguimiento, así que cada paso a «hecho» queda anotado con fecha y usuario. Con el módulo de entrega, el número de seguimiento del transportista es un campo del propio albarán (carrier_tracking_ref). Todo eso viene de serie.
Lo que Odoo no sabe de serie es si ese tracking ha llegado al marketplace. Con un middleware, la cadena pedido → albarán → tracking → confirmación al canal se parte en dos: los dos primeros eslabones en Odoo, los dos últimos en el panel del proveedor. El chatter del albarán dice «hecho», y la prueba de que el comprador vio su número está en otro sistema.
Un conector nativo cierra la cadena en el mismo sitio. En el nuestro de Mirakl, validar el albarán dispara el envío del tracking si la instancia lo tiene activado, y el resultado se escribe en el chatter: una nota si se envió, otra con el error si falló, y otra distinta si el albarán no tenía número de seguimiento y no se envió nada.
Nativo tampoco es magia: 32 fallos con los tests en verde
La parte incómoda es nuestra: «nativo» significa que el código vive en Odoo, no que funcione. Auditamos un conector de marketplace propio antes de ponerlo delante de un vendedor real. La suite daba 236 de 236 en verde, sobre builds reales de Odoo.sh en 19, 18 y 17. Por debajo había 32 fallos reales: 20 de contrato con la API y 12 de versión de Odoo.
Los de contrato eran parámetros que la API exigía y no se enviaban, y campos de respuesta leídos con el nombre equivocado, que devuelven None sin lanzar nada. Cuatro solo salieron llamando: la cabecera de paginación llegaba relativa y a partir de la página uno no se importaba ningún pedido; un 403 por cuota no venía en el formato documentado y se leía como falta de permisos, deteniendo la sincronización entera. Los de versión eran del propio Odoo: un cron que en 17 corre una vez y se apaga solo, un campo de grupos que se llama distinto a partir de 19, una vista de lista que 17 rechaza. La mitad no daba error: daba silencio.
El caso completo —incluido un segundo conector con 163 de 163 en verde que nunca había escrito una línea de log— está en los tests estaban en verde y el conector no funcionaba. La conclusión para quien compara: pide al conector nativo lo mismo que al middleware. Que esté instalado de verdad en tu versión, no solo que compile; que se haya contrastado con la especificación del proveedor y no con sus propios mocks; y que haya hecho al menos una llamada real por familia de endpoint. Si lo heredas de otro, la lista está en auditar un conector Odoo heredado.
Checklist de decisión
- ¿Dónde se reserva el stock, y cuántos sistemas guardan una copia del disponible?
- ¿Quién crea el albarán y la etiqueta?
- ¿Dónde se ve el error cuando una API falla, y lo ve la misma persona que ve el pedido?
- ¿El tracking vuelve al canal automáticamente, y queda anotado en el albarán que volvió?
- ¿Puedes reintentar sin duplicar pedidos o envíos?
- ¿Quién migra el conector cuando salga la siguiente versión de Odoo, y en qué plazo?
- ¿Se ha instalado de verdad en tu versión y probado contra el sandbox del proveedor?
El orden en que se conectan varios canales depende de cuál publica el stock: lo tratamos en vender en varios marketplaces desde un solo Odoo. Los conectores que ya hablan con Amazon, Mirakl, ManoMano, AliExpress y los transportistas están en el catálogo y en integraciones y automatización Odoo; si es para tu propio software, conector Odoo para tu software.
Preguntas frecuentes
¿Un conector nativo siempre es mejor?
No siempre. Es mejor cuando Odoo es el centro operativo y necesitas reglas de negocio, trazabilidad y control desde el ERP. Si Odoo solo recibe un fichero al final del proceso, o si nadie va a mantener código dentro de Odoo, el middleware es la opción razonable.
¿Puedo combinar ambos enfoques?
Sí, pero conviene definir qué sistema manda sobre stock, pedidos, logística y errores, y no dejar ningún estado que exista en los dos a la vez sin una comparación diaria.
¿Cómo compruebo que un conector nativo funciona antes de fiarme de él?
Instalarlo de verdad en tu versión, comparar lo que envía y lee contra la especificación del proveedor y hacer una llamada real al sandbox por familia de endpoint. Un conector nuestro con 236 de 236 tests en verde tenía 32 fallos que solo salieron así.
¿Qué pasa con el conector nativo cuando sale una nueva versión de Odoo?
Hay que migrarlo, y conviene saber quién antes de decidir. En Odoo 17 un ir.cron sin numbercall toma el valor 1 y se desactiva tras la primera ejecución; ese campo ya no existe en 18 ni en 19, y el cambio no avisa al instalar. Nuestros conectores se publican para 19, 18 y 17.
Enlaces útiles dentro de FlexigoTech
Lo que hacemos sobre esto
¿Quieres revisar tu caso?
Miramos tus canales, stock, transportistas y versión de Odoo para proponerte el camino más limpio, y te decimos con claridad si el middleware debe quedarse. Escribe a comercial@flexigobe.com o llama al +34 616 809 504.