Cómo integrar Shopify con un ERP en Chile: lo que nadie te cuenta

Shopify resuelve bien el problema de lanzar una tienda online. Tiene temas, pagos, envíos y una experiencia de compra sólida lista para usar. El problema aparece cuando la tienda empieza a crecer y necesita hablar con el resto de la operación.

Cuando las órdenes de Shopify llegan a un correo y alguien las pasa manualmente al sistema de gestión, el modelo de negocio funciona — pero solo hasta cierto punto. A partir de un volumen que no es tan alto, ese proceso se convierte en el cuello de botella.

Por qué Shopify es diferente de WooCommerce en términos de integración

WooCommerce vive en tu servidor. Tienes acceso directo a la base de datos, puedes instalar código que se ejecuta en el servidor y controlas completamente el entorno. Shopify es SaaS: todo pasa en los servidores de Shopify, y la única forma de integrarse es través de su API.

Eso no es malo. La API de Shopify es una de las mejores del ecosistema e-commerce: bien documentada, estable y con webhooks confiables. Pero significa que la arquitectura de integración es diferente.

En WooCommerce, puedes tener un job que lee la base de datos directamente. En Shopify, todo pasa por la API con límites de tasa. Hay que diseñar la integración teniendo eso en cuenta.

Los flujos que hay que integrar

Antes de escribir código, mapeamos los flujos. En una integración Shopify-ERP estándar, estos son los que siempre aparecen:

1. Stock

El ERP es la fuente de verdad del stock. Shopify muestra lo que hay disponible para venta online. La sincronización es unidireccional: el ERP empuja hacia Shopify, no al revés.

La frecuencia depende del volumen. Para la mayoría de las operaciones, actualizar el stock cada 10 a 15 minutos es suficiente. Para operaciones de alto volumen con stock ajustado, puede necesitarse tiempo real vía webhook desde el ERP.

Un detalle importante: Shopify maneja el stock por variante (talla, color, etc.) y por location (bodega). Si el ERP tiene múltiples bodegas y la tienda solo muestra una parte del stock, la lógica de mapping tiene que ser explícita.

2. Órdenes

Cada orden confirmada en Shopify tiene que crear una orden en el ERP. El mapping de campos no es trivial: el producto en Shopify (identificado por variant_id) tiene que mapear al SKU del ERP, el cliente tiene que existir o crearse, y los datos de despacho tienen que traducirse a la lógica de logística propia.

Los webhooks de Shopify son la herramienta correcta para esto. Shopify notifica en tiempo real cuando se crea o actualiza una orden. La integración recibe el webhook, valida los datos, y crea la orden en el ERP.

3. Clientes

La sincronización de clientes suele ser unidireccional: Shopify hacia el ERP. Cuando un cliente nuevo compra en la tienda, se crea en el ERP. Si el cliente ya existe (por email o RUT), se actualiza.

En operaciones B2B con precios diferenciados por cliente, el flujo puede ser inverso: el ERP tiene la lista de clientes con sus condiciones comerciales, y esos datos se sincronizan hacia Shopify para que la tienda muestre los precios correctos.

4. Precios

Si todos los clientes ven el mismo precio, no hay complejidad. Si hay precios por segmento, por volumen o por condición comercial, el ERP tiene que ser la fuente de verdad y la tienda tiene que consumir esos precios, no generarlos.

Shopify tiene funcionalidad nativa para precios por segmento de cliente (price lists). La integración tiene que mantener esos price lists sincronizados con lo que dice el ERP.

La arquitectura que usamos

Para la mayoría de los casos, la arquitectura que implementamos sigue este patrón:

Shopify → Webhook → API propia → Cola de mensajes → ERP
ERP → Job programado (cada 15 min) → Shopify API (stock + precios)

El componente clave es la capa intermedia: una API propia que recibe los webhooks de Shopify, valida los datos, maneja los errores y habla con el ERP. Esta capa existe por tres razones:

1. Desacopla los sistemas: si el ERP está caído, los mensajes se encolan y se procesan cuando vuelve. Shopify no sabe nada del ERP.
2. Centraliza el logging: cada transacción queda registrada con timestamp, datos de entrada y resultado. Cuando algo falla, no hay que investigar a ciegas.
3. Maneja los casos borde: la lógica de negocio específica vive aquí, no en el webhook de Shopify ni en el ERP.

Los casos borde que más problemas dan

La integración en el camino feliz es la parte fácil. Los problemas reales aparecen en los bordes:

Stock que llega a cero entre la consulta y el pago: Shopify muestra stock disponible en el momento de agregar al carro. Si entre ese momento y el pago alguien más compra el último item, Shopify puede confirmar una venta de un producto sin stock. La solución es una validación en tiempo real contra el ERP en el momento exacto del checkout.

Variantes de Shopify que no mapean a SKUs del ERP: cuando un producto tiene variantes (talla + color), el variant_id de Shopify tiene que mapear inequívocamente al SKU del ERP. Si el mapping no está bien mantenido, las órdenes llegan al ERP con referencias incorrectas.

Devoluciones: Shopify genera un refund con los items devueltos. La integración tiene que actualizar el stock en el ERP, generar la nota de crédito y, si aplica, disparar un flujo de revisión del producto devuelto. Este flujo suele estar ausente en las integraciones con plugins genéricos.

Órdenes en estados intermedios: Shopify tiene varios estados (pending, authorized, paid, fulfilled, cancelled). El ERP tiene sus propios estados. El mapping entre ambos tiene que ser explícito y bidireccional.

Qué evaluar antes de decidir entre plugin o integración propia

No toda integración Shopify-ERP necesita desarrollo propio. La tabla de decisión que usamos:

Criterio	Plugin genérico	Integración propia
ERP es Bsale, Defontana, SAP B1	✓ puede funcionar	No necesario
ERP propio o desarrollado a medida	No	✓
Precios diferenciados por canal	✗ mal soporte	✓
Múltiples bodegas con lógica propia	✗	✓
Volumen >200 órdenes/día	Riesgo	✓
Devoluciones complejas	✗	✓

Lo que aprendimos después de varias integraciones

El tiempo de implementación no lo determina la complejidad técnica sino la claridad del mapeo de flujos. Las preguntas que más tiempo toman responder son de negocio, no de código: ¿quién es la fuente de verdad del precio? ¿qué pasa con una orden que llega fuera del horario de operación? ¿cómo se maneja un cliente que compra online pero retira en tienda?

Esas preguntas tienen que estar respondidas antes de escribir la primera línea de código. Si no lo están, la integración técnicamente correcta falla igual porque modela mal el proceso real.