Integración Shopify ERP: sincronizar inventario y pedidos (Guía 2026)

¿Cómo sincronizas Shopify con un ERP?

Te voy a ahorrar la decepción de buscar “el mejor conector Shopify ERP” durante tres días: una integración con ERP no es un conector que compras, es un contrato que diseñas. La parte técnica -conectar dos APIs- es la fácil. La difícil es decidir, entidad por entidad, quién es dueño de qué. El modo de falla que rompe tiendas reales es siempre el mismo: dos sistemas creen al mismo tiempo que son dueños del inventario, y el resultado es sobreventa (oversell), pedidos duplicados y surtido doble.

La forma corta: eliges una fuente de verdad por entidad. El ERP es dueño del inventario, los productos, los clientes y los precios. Shopify es dueño del pedido en el momento del checkout. Los pedidos suben al ERP, el inventario y el catálogo bajan a Shopify, y el surtido regresa para cerrar el pedido. Sincronizas con webhooks para lo urgente, más un job de conciliación nocturno e idempotencia para lo correcto. Compras un conector para los flujos estándar; construyes a medida cuando tienes lógica B2B rara.

Esto lo digo por trabajo de verdad: builds de Shopify para Hazil Studios y la integración de Mercanto, un marketplace B2B mayorista donde el inventario se reparte entre canales y un solo número mal sincronizado le cuesta dinero a alguien. En todos esos proyectos la columna vertebral fue la misma tabla de propiedad de entidades, y se apoya exactamente en el mismo patrón de webhooks más conciliación que uso para cualquier integración seria. Vamos a esa tabla, porque es el 80% del diseño.

¿Quién debe ser dueño de cada entidad? (la pregunta de la fuente de verdad)

No preguntes “¿el maestro de datos es Shopify o el ERP?”. Esa pregunta no tiene respuesta útil porque la respuesta depende de la entidad. Pregúntala fila por fila.

La regla que no se negocia: exactamente un escritor por campo. Todos los demás son de solo lectura sobre ese campo. Cuando dos lados pueden escribir el mismo campo -inventario ajustado en el Admin de Shopify y en el ERP- entras en el “ping-pong”: el ERP empuja stock=10, Shopify dispara un webhook de cambio, el ERP lo interpreta como evento nuevo, y se forma un loop. La propiedad a nivel de campo le gana a la propiedad a nivel de sistema, y esta es la decisión de diseño más difícil e importante de todo el proyecto.

La tabla de propiedad de entidades

Esta tabla es el ancla de todo. Defínela en papel antes de tocar una sola API.

Fíjate en clientes: no es “uno u otro”, es partido por campo. Shopify es dueño de la identidad del storefront (la cuenta, el email de marketing); el ERP es dueño del registro de A/R, los términos de crédito y la exención de impuestos. Los mapeas entre sí, no los duplicas con dos escritores peleando.

¿Cuáles son los seis flujos de datos y en qué dirección van?

Antes de elegir herramienta tienes que ver la arquitectura, y la arquitectura es direccional y asimétrica. El catálogo y el inventario bajan a Shopify; las transacciones suben al ERP; el surtido regresa.

Los seis flujos

1. Pedidos: Shopify -> ERP. En orders/create y orders/paid creas la orden de venta en el ERP. Shopify acuña el order ID porque ahí ocurrió la venta.
2. Inventario: ERP/WMS -> Shopify. Casi siempre multi-location. Shopify es una réplica de lectura del “disponible para vender”: empujas en cada cambio de stock, pero algunos de estos cambios -comprometido, safety stock- no emiten evento, y por eso la conciliación nocturna es obligatoria, no opcional.
3. Productos / precios: ERP o PIM -> Shopify. Los datos maestros (master data: SKU, costo, descripción, listas de precios B2B por compañía) viven en el ERP; Shopify es dueño solo de campos de merchandising (copy, SEO, imágenes, colecciones).
4. Clientes: Shopify <-> ERP, partido por campo. Shopify crea la identidad, el ERP es el sistema de registro financiero.
5. Surtido + guía: ERP/3PL -> Shopify. Marcas fulfilled y escribes el número de guía, lo que dispara el correo al cliente y cierra el pedido.
6. Devoluciones / reembolsos: Shopify -> ERP. El refund genera un credit memo y un restock en el ERP, que vuelve a bajar como inventario. Modélalo de forma explícita; dejarlo manual desincroniza A/R e inventario en una semana.

El detalle que evita el oversell: empuja ATP, no on-hand

Este es el matiz que casi nadie incluye y es la causa número uno de sobrevender. No sincronices el on-hand crudo. Sincroniza el ATP (available-to-promise):

ATP = On Hand − Comprometido − Safety Stock + En tránsito

El término en tránsito es opcional y agresivo: súmalo solo si confías en la fecha y cantidad de recepción, porque promete stock que todavía no llega. Si empujas on-hand crudo, vendes unidades que ya estaban comprometidas a pedidos abiertos, a mayoreo o a otro canal. Y aquí está el porqué el ERP tiene que ser dueño del inventario: es el único sistema que ve los compromisos de todos los canales a la vez -Shopify, un marketplace B2B tipo Mercanto, Amazon, retail físico-. Shopify no puede calcular ATP porque no ve el resto del mundo.

¿Tiempo real o por lotes? Por qué la respuesta es un híbrido

Esta es una falsa disyuntiva. La respuesta de producción es híbrida, y se decide por entidad.

• Tiempo real (webhooks) para la ruta crítica donde la latencia cuesta dinero o rompe la experiencia: orders/create, orders/paid, inventory_levels/update, fulfillments/create. Los webhooks son push, no consumen rate limit y te dan el pedido en el ERP en segundos.
• Casi tiempo real para inventario ERP -> Shopify: empujas en cada cambio de stock, pero con tope de frecuencia. El tiempo real puro es innecesario y caro en rate limit.
• Por lotes para lo voluminoso y de cambio lento: catálogo completo, listas de precios, maestro de clientes. Nightly o por delta cada 5-15 minutos.

La tercera pata que nadie quiere construir: conciliación

Aquí va mi opinión sin diplomacia: cualquier integración sin un job de conciliación es una bomba de tiempo. Los webhooks son necesarios pero jamás suficientes. Son entrega at-least-once: se pierden, se duplican, tu servicio tiene downtime, y Shopify borra la suscripción del webhook después de fallas consecutivas. Peor: cambios en comprometido y safety_stock dentro del ERP ni siquiera disparan webhooks. Si confías solo en el stream de eventos, un solo evento perdido es sobreventa silenciosa hasta que un cliente se queja.

La conciliación es un job programado -nocturno como mínimo, por hora si vendes rápido- que jala el estado autoritativo del ERP y lo vuelve a imponer sobre Shopify, sanando cualquier drift. Es exactamente el mismo patrón de webhooks más conciliación que aplica a cualquier integración seria: tiempo real para la velocidad, lotes para el volumen, conciliación para la verdad.

El modelo mental honesto es consistencia eventual. Los dos sistemas convergen; nunca están perfectamente sincronizados en cada instante. No pelees contra eso: diseña buffers de safety stock en SKUs de alta velocidad y monitorea el drift en vez de fingir que tendrás cero milisegundos de desfase.

¿Por qué mi inventario siempre sale mal? (idempotencia y mapeo)

Esta es la plomería poco glamorosa que tumba los go-lives. Dos cosas: idempotencia y mapeo.

Idempotencia: porque Shopify entrega duplicados

Shopify garantiza entrega at-least-once, así que recibir el mismo evento dos veces es lo normal, no un caso borde. Reintenta un webhook fallido hasta 8 veces en una ventana de ~4 horas con backoff creciente, y si las entregas siguen fallando a lo largo de un periodo de 24 horas, elimina la suscripción. Eso te obliga a dos cosas:

1. Responde 2xx en menos de 5 segundos y procesa async vía una cola. Si haces trabajo lento del ERP antes de responder, Shopify hace timeout, reintenta y fabrica los duplicados que temes.
2. Deduplica en el header X-Shopify-Webhook-Id (estable entre reintentos del mismo evento) con un store de eventos procesados cuyo TTL supere holgadamente la ventana de reintentos (24h+ es lo seguro). Y del lado del ERP, llave la creación de la orden de venta en el Shopify order ID, para que un webhook reenviado nunca genere una orden duplicada -la causa número uno de pedidos enviados dos veces.

A partir de la versión 2026-04 del Admin API, Shopify exige idempotency keys en ciertas mutaciones de cambio de estado, incluidos reembolsos y ajustes de inventario. La idempotencia dejó de ser higiene opcional y es parte del contrato de la API.

Mapeo: el SKU es frágil y las locations no son 1:1

Las tablas de mapeo son artefactos de primera clase, no un detalle. Necesitas dos:

• Shopify variant GID <-> item del ERP. El SKU es la llave de unión, pero el match es exacto y sensible a mayúsculas: un espacio al final basta para romperlo. En NetSuite no hay tolerancia.
• Shopify location <-> almacén del ERP. Casi nunca mapean 1:1. Un almacén con zonas puede respaldar varias locations de Shopify, o varios sitios físicos consolidan en un centro de surtido.

Los bundles y kits son la trampa clásica: el ERP descuenta componentes vía BoM, Shopify ve un solo SKU. La mayoría de los conectores nativos manejan esto mal.

Las realidades de la API de Shopify en 2026

• GraphQL-only para apps públicas nuevas desde abril de 2025; REST está en modo mantenimiento.
• Rate limit por costo, no por número de requests: un bucket leaky de ~1,000 puntos (2,000 en Plus) que se repone por plan -100 pts/seg en Standard, 200 en Advanced, 1,000 en Plus, 2,000 en Enterprise-, y ninguna query individual puede costar más de 1,000 puntos. Un loop ingenuo sobre 40,000 SKUs te va a limitar (throttling); usa Bulk Operations (JSONL async), que prácticamente no consumen el bucket, para barridos grandes de catálogo o conciliación.
• inventorySetQuantities empuja un valor absoluto desde la fuente de verdad (hasta 250 items por request) y soporta compare-and-set para que escrituras concurrentes no se pisen. Úsalo solo cuando tu sistema es la fuente de verdad; si no, inventoryAdjustQuantities. Confundir set con adjust corrompe cantidades.

¿Comprar un conector o construir middleware a medida?

La decisión de build-vs-buy es downstream de la propiedad y los flujos, no el punto de partida. Una vez que fijaste quién es dueño de qué, la pregunta del conector casi se responde sola. Hay tres enfoques.

iPaaS / conector pre-armado

Celigo, Boomi, Workato, o conectores nativos del ERP (Business Central trae uno gratis, Odoo tiene primera parte y PRO). Es el time-to-value más rápido para B2C estándar contra un ERP mainstream. Celigo entiende el modelo de datos de NetSuite de fábrica y trae flujos pre-armados de pedidos, items, inventario, surtido, reembolsos y listas de precios B2B. El vendor mantiene los mappings contra los cambios de la API de Shopify -eso vale oro.

Middleware a medida

Tu propio servicio: receptor de webhooks + cola + store de dedup + DB de mapeo + worker de conciliación, todo sobre un esquema canónico interno. Es la opción correcta cuando la lógica es no estándar: listas de precios B2B por compañía, fan-out a múltiples marketplaces, asignación custom, bundles/BoM, o un ERP bespoke. Aquí el negocio es la lógica, y vas a pelear contra el conector. Adopta un modelo canónico (Product, Variant, InventoryRecord, Order, Customer, PriceList) al que ambos lados mapean: así un futuro cambio de NetSuite a SAP es reescribir un adaptador, no todo.

Point-to-point directo

Un cron que lee una API y escribe la otra, sin cola, sin idempotencia, sin conciliación. Solo aceptable para un flujo trivial. Se pudre rápido y se vuelve spaghetti N×N en cuanto llega un tercer sistema (un 3PL, un marketplace, un segundo canal). Evítalo.

Mi veredicto por escenario

Tienda Shopify sola + ERP mainstream (NetSuite, Business Central) + B2C vainilla: compra el conector. No construyas; vas a pasar meses reconstruyendo lo que una suscripción de $200-$1,000/mes ya mantiene. B2B/mayoreo, un marketplace, multi-canal, asignación custom o un ERP que los conectores manejan mal (SAP B1, legacy): construye middleware. Y el destino real de la mayoría de marcas que crecen es el híbrido 80/20: iPaaS para la plomería estándar más un servicio delgado a medida para el 20% raro. Eso no es un fracaso, es un destino legítimo. Antes de firmar nada, audita el conector contra TU ciclo de vida del pedido: surtidos parciales, reembolsos, devoluciones, precios B2B, multi-moneda. Ahí es donde mueren los proyectos a mitad de camino.

¿Cuánto cuesta de verdad una integración Shopify-ERP en 2026?

Hablemos de dinero real, porque el precio de lista esconde la mitad del costo. (Si todavía estás dimensionando la tienda misma, tengo el desglose en cuánto cuesta una tienda Shopify.)

• Conectores de app-store / nativos: ~$200-$600/mes. El camino de Odoo es el más barato para SMB y mid-market; el conector de Business Central viene gratis incluido.
• Celigo (Shopify a NetSuite): ~$800-$1,800/mes de suscripción a $10M-$100M de GMV, más $15K-$50K de implementación con partner certificado a $150-$250 USD/hora. Año uno all-in: ~$60K-$150K.
• Boomi: desde ~$99/mes pay-as-you-go; mid-market típicamente $1,500-$5,000/mes, más implementación de $50K-$200K. Ojo con los caps de conectores/mensajes que en 2025 dispararon renovaciones 50-100%.
• Middleware a medida: entre 20 y 40 mil USD de pago único, más hosting y mantenimiento. Es un trade contra los fees recurrentes por volumen del conector.

Lo realista a 36 meses para una marca Shopify Plus de $25M de GMV sobre Celigo ronda los **$182K**: ~$45K de implementación + ~$47K de suscripción + ~$90K de medio FTE de operaciones. Eso es frente a un año uno de $60K-$150K cuando la implementación es más pesada; este ejemplo asume una implementación de alcance medio ($45K) amortizada sobre tres años. Esa última línea de operaciones es la que todos olvidan: un conector nunca es set-and-forget. Sigue necesitando un dueño de operaciones, monitoreo y conciliación. Ese medio FTE no desaparece porque compraste software; solo cambia de nombre.

¿Cómo defines el alcance y las fases del proyecto?

El playbook práctico para llegar a producción sin sobrevender el primer día. La regla de oro: nunca big-bang. Corta por entidad.

1. Escribe la matriz de propiedad. Una fila por entidad, un solo dueño y dirección por campo. Esto es el 80% del diseño y va primero.
2. Limpia los datos y congela la tabla de mapeo. SKUs duplicados, clientes repetidos, stock viejo. La tabla SKU/variant/location es una compuerta de go-live: si un variant o una location no está mapeada, no sales.
3. Levanta el andamiaje de confiabilidad ANTES del corte. Dead-letter queue para eventos fallidos, store de idempotencia, job de conciliación, y un dashboard de drift con alertas. Nada de esto se construye después; se construye antes.
4. Corte por fases, entidad por entidad. Empieza con inventario de solo lectura ERP -> Shopify (el más bajo riesgo, solo lees). Luego pedidos Shopify -> ERP. Luego surtido y guía. Al final clientes y precios. Cada fase se estabiliza antes de la siguiente.
5. Instrumenta todo. Loggea cada evento de sync, expón conteos de drift por entidad (Shopify vs ERP), alerta cuando crezca la dead-letter queue. No puedes confiar en lo que no puedes observar -y este es justo el tipo de dashboard interno de operaciones que hace la diferencia entre dormir tranquilo y enterarte del oversell por un ticket de soporte.

Preguntas frecuentes: integración Shopify-ERP

¿Qué sistema debe ser dueño del inventario?

El ERP o el WMS. Es el único sistema que ve los compromisos de todos los canales -Shopify, mayoreo, marketplaces, retail-. Empuja ATP (on-hand menos comprometido menos safety stock más en tránsito) en una sola dirección hacia Shopify. Nunca dejes que Shopify escriba stock de vuelta como autoritativo.

¿Tiempo real o por lotes?

Híbrido. Webhooks para pedidos e inventario en la ruta crítica, lotes para catálogo y clientes que cambian lento y pesan mucho, más un barrido de conciliación nocturno que re-impone la verdad del ERP. Los webhooks son necesarios pero nunca suficientes: se pierden y se duplican.

¿Necesito un iPaaS o puedo construir a medida?

Compra un conector para flujos estándar de NetSuite o Shopify -es más rápido y el vendor lo mantiene contra cambios de API-. Construye middleware cuando tengas listas de precios B2B, bundles/BoM, múltiples marketplaces o un ERP bespoke. El híbrido -iPaaS más un servicio delgado para el 20% raro- es un destino legítimo.

¿Por qué mi inventario sale mal?

Casi siempre por dos causas: mapeo de SKU o location mal hecho (un espacio al final del SKU basta), o webhooks perdidos/duplicados sin un job de conciliación que los corrija. Arregla la tabla de mapeo, agrega el barrido nocturno, y empuja ATP en vez de on-hand crudo.

La única decisión que debes acertar

Si te llevas una sola cosa: la propiedad de entidades y el job de conciliación deciden si sobrevendes o no, sin importar qué enfoque de build elijas. La matriz en papel primero, un escritor por campo, sincronización híbrida con conciliación, y después eliges conector o a medida.

Hay dos cosas que tienes que ser dueño tú mismo, compres lo que compres: la matriz de fuente de verdad y el job de conciliación. Esas no las terceriza un conector. Ese es el trabajo de integración que hago -Shopify + ERP + marketplaces-, así que si estás dimensionando uno, escríbeme.