La pregunta llega casi siempre en el mismo momento: ya vendes en Amazon, ya tienes Odoo, y alguien te ha pasado el presupuesto de una plataforma intermedia que lo conecta todo. La decisión no es «caro o barato». Es de quién son las credenciales, cuántos minutos pasan entre que Amazon sabe algo y lo sabe tu almacén, y a quién llamas el día que la SP-API cambie.
Son tres vías, no dos
Middleware de pago: un servicio externo habla con Amazon, normaliza los datos y los empuja a Odoo. Conector nativo: un módulo dentro de Odoo que habla con la SP-API directamente. Y una tercera que casi todo el mundo olvida: Odoo Enterprise trae su propio conector de Amazon, que importa pedidos y crea el cliente y el albarán. Si lo único que necesitas es que los pedidos entren y ya pagas Enterprise, empieza por ahí antes de contratar nada. Las diferencias están desglosadas en la comparativa de conectores de Amazon para Odoo.
El coste que se ve y el que no
La cuota mensual del middleware es la parte visible, y casi nunca es la cara. Lo caro es que el coste crece con tu éxito: los tramos por pedidos hacen que cuanto mejor vendes, más pagas, y ese dinero no compra funcionalidad nueva. El conector nativo tiene el perfil contrario, y hay que decirlo entero: se paga una vez y después se mantiene. Amazon retira versiones de la SP-API, Odoo saca versión mayor cada año y alguien tiene que estar detrás. Un módulo sin mantenimiento acaba saliendo más caro que cualquier cuota.
Latencia: dónde se pagan los minutos
Cada salto añade tiempo. Amazon → middleware → Odoo son dos colas en vez de una, cada una con sus reintentos y su ventana de sincronización. Donde eso se paga en dinero es en la confirmación de envío: Amazon te da un plazo para subir el seguimiento y penaliza en métricas de cuenta si llegas tarde, un problema desarrollado en cuando el tracking no llega a Amazon. Ahora la otra mitad, que también es verdad: parte del retraso no lo pone el intermediario, lo pone Amazon. El inventario de FBA se publica por informe asíncrono, y ahí el conector nativo tampoco hace magia.
De quién son las credenciales y por dónde pasan los datos del comprador
Con conector nativo autorizas la aplicación en tu Seller Central: el token de refresco vive en tu Odoo y la cuota de llamadas a la API la gastas tú, al ritmo que tú decides. Con middleware, los datos del comprador —nombre, dirección, teléfono— pasan por un tercero. Eso no es malo por sí solo: Amazon tiene una política de protección de datos y hay proveedores serios que la cumplen. Pero es una pregunta que hay que hacer y ver respondida por escrito, no un detalle que se resuelve en la demo.
Cuatro preguntas antes de firmar, válidas para los dos modelos: ¿de quién es el token de refresco? ¿Quién procesa los datos del comprador? ¿Qué me llevo si me voy, el mapa de SKU y el histórico de pedidos incluidos? ¿En cuántas horas hay parche cuando Amazon cambia algo?
Quién lo arregla cuando Amazon cambia la API
Amazon cambia. Versiona endpoints, apaga los viejos y aprieta los límites de llamadas. Con middleware, el arreglo lo hace el proveedor y tú esperas; suele ser rápido, porque el fallo le afecta a todos sus clientes a la vez. Con módulo propio, lo arregla quien te lo hizo, y ahí la respuesta depende enteramente de a quién se lo compraste y de si mantiene el módulo en Odoo 17, 18 y 19 o solo en la versión en la que te lo vendió. Los fallos concretos que más aparecen están en errores frecuentes de la SP-API en Odoo.
Cuándo el middleware es la respuesta correcta
Cuando vendes en ocho canales y Amazon es uno más: pagar una cuota por no mantener ocho integraciones es un buen trato. Cuando estás probando el canal y no sabes si seguirás en seis meses. Cuando no tienes equipo técnico ni partner y necesitas que algo funcione el lunes. Y cuando ya lo tienes montado y funciona: sustituir una integración que no duele es gastar dinero y riesgo para no mejorar nada. Si el único motivo para moverte es que «suena caro», compara antes la factura de un año con lo que cuesta mantener un módulo.
Cuándo compensa el nativo, y qué hacemos nosotros
Compensa cuando el volumen sube, cuando los canales se reducen a dos o tres serios, o cuando la operación necesita más que pedidos: liquidaciones cuadradas línea a línea, FBA como ubicación real, devoluciones y reembolsos. El conector de Amazon para Odoo trabaja contra la SP-API con tus propias credenciales, en Odoo 17, 18 y 19, y en Odoo 20 el día que salga. La parte de inventario está contada en FBA como almacén dentro de Odoo. Y si lo que tienes hoy es middleware, cómo se migra sin parar la operación explica el orden de los pasos.
Preguntas frecuentes
¿Puedo tener middleware y conector nativo a la vez?
Durante una migración sí, pero solo uno puede escribir. Si los dos confirman envíos o publican stock, Amazon recibe órdenes contradictorias y aparecen duplicados. Se reparte por canal o por tipo de dato, nunca a ver cuál llega antes.
¿El conector nativo necesita una cuenta de desarrollador de Amazon?
La aplicación tiene que estar registrada bajo un perfil de desarrollador, pero quien la autoriza eres tú, desde tu Seller Central. El token de refresco que sale de esa autorización se guarda en tu Odoo y puedes revocarlo cuando quieras. No revendemos acceso.
¿Me llevo el histórico si dejo el middleware?
Lo imprescindible son el mapa de SKU y los pedidos abiertos. El histórico cerrado se puede traer o dejar archivado: no bloquea el arranque. Pedir por escrito cómo se exporta, antes de firmar, evita la sorpresa.
Enlaces útiles dentro de FlexigoTech
Lo que hacemos sobre esto
¿Estás decidiendo entre middleware y módulo propio?
Dinos cuántos pedidos al mes mueves por Amazon, en cuántos canales más vendes y qué te cuesta hoy el intermediario. Si la respuesta correcta es quedarte donde estás, te lo decimos. Escribe a comercial@flexigobe.com o agenda una llamada.