Integración de Shopify con CRM: cómo contratar al equipo

Una integración de Shopify con CRM parece un trabajo pequeño. Los pedidos llegan a HubSpot o Salesforce, los clientes se convierten en contactos y ventas deja de copiar datos entre pestañas. En la práctica es un contrato entre dos sistemas que no se ponen de acuerdo sobre qué es un cliente.

La mayoría de los consejos para contratarla dicen lo mismo: define el alcance, pide referencias, compara presupuestos. Es correcto e incompleto. Se salta lo que decide si la sincronización sobrevive a su primera mala semana: el mapeo de datos, la gestión de fallos, el coste a doce meses y quién es responsable de la sincronización cuando la agencia se va.

Esta es una guía de compra para responsables de e-commerce y operaciones. Muestra cómo definir el alcance, elegir entre un conector, n8n y código a medida, acordar un mapeo, redactar un contrato y planificar un calendario. Los costes aparecen como formas, y cualquier cifra de ejemplo está marcada como ilustrativa.

Integración de Shopify con CRM: qué cubre el alcance#

Antes de comparar proveedores, escribe qué debe hacer la integración. Un equipo solo puede presupuestar lo que tú puedas describir, y un briefing vago produce un precio cerrado vago. El alcance de una integración de Shopify con CRM se reduce a cuatro decisiones: qué sistemas, qué objetos, en qué dirección y con qué frescura deben estar los datos.

Si te saltas alguna, cada propuesta esconde un conjunto distinto de supuestos. Acabas comparando precios de trabajos diferentes.

Los objetos que realmente se sincronizan#

La mayoría de las tiendas necesita cuatro objetos: clientes, pedidos, reembolsos y consentimiento de marketing. Las configuraciones grandes añaden productos e inventario (normalmente a cargo de un ERP), suscripciones, empresas B2B y tickets de soporte. Cada objeto es un mapeo propio, un ciclo de pruebas propio y una forma propia de fallar.

Nombra el CRM y cada una de las otras apps en el mismo documento. Cuenta objetos y sistemas, no herramientas: dos sistemas con cuatro objetos cada uno son ocho mapeos.

Unidireccional, bidireccional y fuente de verdad#

Unidireccional significa que Shopify escribe y el CRM lee. Bidireccional significa que ambos sistemas pueden cambiar el mismo campo, y ahí es donde crecen los presupuestos, porque cada campo compartido necesita una regla de conflicto.

Elige una fuente de verdad por campo, no por sistema. Shopify es dueño de los totales del pedido, el estado del pago y la dirección de envío en el momento de la compra. El CRM es dueño de la etapa del ciclo de vida, el responsable de la cuenta, las notas de ventas y la etapa del deal.

Por defecto, usa sincronización unidireccional para los datos de comercio y escribe de vuelta solo lo que la tienda necesita, como un segmento o una etiqueta. No bidireccional en todo. Unidireccional con dos escrituras de vuelta precisas.

Qué tan frescos deben estar los datos#

Tiempo real suena bien y cuesta más. Un comercial que llama tras un checkout abandonado necesita minutos. Un informe financiero necesita un cierre diario. Escribe los objetivos como números en el briefing, por ejemplo: los pedidos llegan al CRM en cinco minutos, las actualizaciones de cliente en una hora y los totales se concilian cada noche.

Shopify te da dos herramientas para esto: los webhooks para eventos en vivo y la Admin GraphQL API para lecturas, cargas históricas y operaciones masivas. Ambas tienen límites de uso, y esa es la primera razón por la que una sincronización necesita una cola.

Conector, n8n o código a medida: cuándo gana cada uno#

Hay tres formas de construir esta integración, y cada una traslada coste y riesgo a un lugar distinto. La elección correcta depende de la lógica que necesites y de tu volumen de pedidos, no de qué herramienta esté de moda.

Conector prediseñado: rápido, limitado#

Un conector prediseñado es una app de la Shopify App Store o del marketplace del CRM. Pagas una suscripción, a menudo escalonada por volumen o funciones, y configuras en lugar de construir. Gana cuando tus necesidades encajan con su modelo fijo: objetos estándar, una dirección, sin reglas a medida.

Pierde en el primer campo personalizado, la primera regla condicional o el segundo sistema. Normalmente no puedes cambiar cómo reintenta, y a menudo no puedes ver por qué falló un registro.

Middleware con n8n: control sin una construcción completa#

n8n es una herramienta de workflows que puedes alojar tú mismo o usar en la nube. Un workflow recibe el webhook de Shopify, transforma el payload, llama a la API del CRM y gestiona los errores en un lienzo que se puede leer. El coste es el hosting o un plan más las horas de construcción. Nuestra comparativa de n8n, Zapier y Make cubre la mecánica de precios y los límites.

Gana en tiendas medianas con dos o tres sistemas y reglas a medida: reintentos, ramificaciones y workflows de error vienen incluidos. Pierde con volúmenes muy altos, o cuando la lógica necesita estructura de software como tests y versiones publicadas. La documentación de n8n describe un modo cola para escalar, pero llegados a ese punto una app a medida merece un presupuesto.

App a medida: cuando la lógica es tuya#

Una app a medida es código que te pertenece: un servicio en Next.js o Node con una cola y una base de datos. Encaja con volumen alto, precios complejos, jerarquías B2B y todo lo que necesite tests y CI. El coste es la construcción más alta más un compromiso de mantenimiento, porque Shopify publica versiones de la API según un calendario y retira las antiguas.

Forma del coste de cada opción a 12 meses#

Los precios cambian, así que describimos primero la forma de cada opción y luego hacemos un ejemplo ilustrativo. El encaje y el control van antes que el dinero.

La elección cambia con la lógica y el volumen. Reglas de negocio pesadas o cifras de pedidos muy altas te acercan al código a medida, y una sincronización unidireccional simple de objetos estándar puede no justificar nada más que un conector.

Tomemos una tienda con 5.000 pedidos al mes, un CRM y tres flujos (ilustrativo). Un conector cuesta una cuota mensual y una tarde de configuración, hasta que una petición de campo personalizado obliga a una solución provisional o a una segunda herramienta. Una construcción con n8n podría llevar de 40 a 80 horas más hosting y unas pocas horas mensuales de mantenimiento. Una app a medida podría costar varias veces esa construcción, más un bloque de mantenimiento permanente. Cuenta las soluciones provisionales y los fallos a doce meses, no solo la factura.

Mapeo de datos entre Shopify y el CRM#

El mapeo es el contrato. Enumera cada campo que se mueve, de dónde viene, dónde aterriza, en qué dirección viaja y quién gana un conflicto. Escríbelo antes de la construcción y haz que el equipo lo firme.

Flujo de mapeo de datos

1. 01Evento de ShopifyCambio de cliente, pedido, reembolso o consentimiento
2. 02Mapear y deduplicarCapa intermedia: n8n o app a medida
3. 03Puerta de consentimientoLos bloqueados no pasan al email
4. 04Escribir en destinosCRM, ERP y plataforma de email
5. 05Guardar ID externoSe escribe de vuelta en Shopify

Flujo de datos desde un evento de Shopify, con mapeo y puerta de consentimiento, hasta CRM, ERP y email, con un ID externo de vuelta

Lee el flujo de izquierda a derecha. Un evento sale de Shopify, la capa intermedia lo mapea a campos del CRM y deduplica, una puerta de consentimiento decide si la plataforma de email recibe el contacto, y el ID del registro del CRM se escribe de vuelta en Shopify como ID externo.

Usa la tabla como punto de partida, no como plantilla. Tu catálogo, tu proceso de ventas y tus mercados cambiarán algunas filas.

Clientes y contactos#

Haz la coincidencia por email más el ID de cliente de Shopify. El email solo falla cuando un cliente cambia de dirección o compra como invitado con otra. Guarda el ID de Shopify en una propiedad personalizada del CRM para que cada evento posterior actualice el mismo registro en lugar de crear un duplicado. En Salesforce, añade un campo de ID externo y haz upsert sobre él.

Las compras como invitado no tienen ID de cliente. Decide si se convierten en contactos y usa el email como clave hasta que exista una cuenta.

Pedidos, líneas y deals#

Un pedido se mapea a un deal en HubSpot, o a una oportunidad o un pedido en Salesforce, según si ventas hace seguimiento. Los equipos de e-commerce puro suelen saltarse los deals y escriben los totales del pedido y la fecha del último pedido en el contacto. Los equipos B2B con pedidos borrador y presupuestos normalmente quieren un deal por pedido.

Conserva el número de pedido y el ID de pedido de Shopify en el registro. Copia la moneda junto con el importe y nunca conviertas en silencio.

Reembolsos y cancelaciones#

Un reembolso actualiza el registro del pedido. Nunca lo borra. Borrar rompe los informes de ingresos y la pista de auditoría. Escribe el importe reembolsado, la fecha y un estado como reembolsado parcialmente. Guarda importes, no indicadores, porque un indicador no puede decir cuánto. Una cancelación mueve el deal a una etapa cerrada con un motivo.

Consentimiento de marketing y cumplimiento#

El consentimiento es una puerta, nunca un campo que sobrescribir. Shopify registra el consentimiento de marketing por email y SMS de cada cliente. El CRM y la plataforma de email solo deben marcar un contacto como suscrito cuando Shopify lo diga, y una baja en cualquiera de los dos lugares debe propagarse. Una importación de lista en el CRM nunca debe devolver a un contacto al estado suscrito.

En EE. UU. la TCPA regula los mensajes de texto de marketing. En España se aplica el RGPD, y varios países de Latinoamérica tienen sus propias leyes de protección de datos. Trata las solicitudes de eliminación del mismo modo: una recibida en Shopify debe llegar al CRM. Confirma las reglas con tu asesor legal.

Webhooks, idempotencia, reintentos y conciliación#

Las construcciones baratas funcionan en el camino feliz: llega un webhook, el CRM acepta el registro, listo. La producción es el otro camino. El CRM da timeout, Shopify envía el mismo evento dos veces, un límite de uso te bloquea en un día de ventas. La gestión de fallos es la parte que los compradores nunca preguntan, así que es la parte por la que hay que preguntar.

Los webhooks de Shopify se entregan al menos una vez y sin garantía de orden, así que los duplicados y los eventos tardíos son normales. Para una visión más amplia de los pipelines de eventos, lee nuestro artículo sobre pipelines de webhooks para integraciones con IA. El camino seguro tiene cinco pasos.

1. Verifica la firma

   Calcula el HMAC del cuerpo sin procesar con el secreto de tu app y compáralo con la cabecera X-Shopify-Hmac-Sha256.

2. Confirma rápido

   Devuelve un 200 en pocos segundos y empuja el evento a una cola.

3. Deduplica

   Busca la clave del evento. Si ya lo has visto, descártalo.

4. Haz upsert en el CRM

   Escribe por ID de Shopify para que un replay actualice el registro en lugar de duplicarlo.

5. Reintenta o aparca

   Reintenta con backoff. Tras el límite, mueve el trabajo a una dead-letter queue y avisa.

Verifica, confirma y luego procesa#

Verifica la firma HMAC sobre el cuerpo sin procesar, responde con un 200 rápido y haz el trabajo con el CRM más tarde en una cola. Si llamas al CRM dentro de la petición del webhook, un CRM lento se convierte en entregas fallidas, y Shopify acabará dejando de llamar. El handler de abajo es un route handler de Next.js. Comprueba los nombres de las cabeceras en la documentación antes de copiarlo.

import { createHmac, timingSafeEqual } from "node:crypto";

// Placeholder: use Redis or a table with a unique constraint in production
const seen = new Set<string>();

export async function POST(req: Request) {
  // The HMAC covers the exact bytes Shopify sent, so read the raw body
  const raw = await req.text();
  const received = req.headers.get("x-shopify-hmac-sha256") ?? "";
  const expected = createHmac("sha256", process.env.SHOPIFY_API_SECRET!)
    .update(raw, "utf8")
    .digest("base64");

  const a = Buffer.from(received);
  const b = Buffer.from(expected);
  if (a.length !== b.length || !timingSafeEqual(a, b)) {
    return new Response("Invalid signature", { status: 401 });
  }

  const topic = req.headers.get("x-shopify-topic") ?? "";
  const eventId =
    req.headers.get("x-shopify-event-id") ?? req.headers.get("x-shopify-webhook-id") ?? "";
  const key = `${topic}:${eventId}`;
  if (seen.has(key)) return new Response("Duplicate", { status: 200 });
  seen.add(key);

  // Hand off to a queue worker and answer fast
  await enqueue({ key, topic, payload: JSON.parse(raw) });
  return new Response("OK", { status: 200 });
}

async function enqueue(job: { key: string; topic: string; payload: unknown }) {
  // Replace with your queue client
  console.log("queued", job.key);
}

El set en memoria es un marcador de posición. En producción la clave del evento vive en Redis o en una tabla de base de datos con una restricción de unicidad, para que sobreviva a los reinicios y funcione entre instancias.

Claves de idempotencia y eventos duplicados#

Idempotente significa que procesar el mismo evento dos veces da el mismo resultado que procesarlo una. Registra la clave del evento antes de actuar y usa upserts por ID de Shopify en lugar de creaciones. Sin eso, un reintento crea un segundo deal y tu pipeline cuenta doble.

Reintentos, dead-letter queues y límites de uso#

Las APIs de los CRM fallan y limitan. Reintenta con backoff exponencial y jitter para que mil trabajos fallidos no golpeen la API en el mismo segundo. Tras un número fijo de intentos, aparca el trabajo en una dead-letter queue: un lugar de espera para los eventos que necesitan a una persona, con el payload y el error adjuntos. Una alerta llega a un canal que alguien lee.

Una cola también absorbe los picos de ventas flash dentro de los límites de la API de ambas partes. Pregunta a cualquier candidato qué pasa cuando el CRM está caído dos horas. La respuesta debería incluir las palabras cola, backoff y replay.

Conciliación nocturna como red de seguridad#

Los webhooks pueden perderse. Un trabajo nocturno compara el día anterior: pedidos, reembolsos y clientes nuevos en Shopify frente al CRM. Los huecos se reparan obteniendo los registros que faltan mediante la Admin GraphQL API y haciendo upsert. La documentación para desarrolladores de HubSpot enumera los endpoints de lotes y búsqueda que mantienen barato este trabajo.

El trabajo también escribe un informe breve. Ese informe es cómo sabes que la sincronización funciona, en lugar de suponerlo.

Ruta segura de sincronización

1. 01Llega el webhookShopify envía el evento
2. 02Verificar HMACFirma inválida: rechazada
3. 03Buscar ID de eventoSe revisan tema e ID

• ADuplicadoYa visto, descartado
• BEvento nuevo: escribir en CRMUpsert por ID de Shopify
  1. Registro actualizadoEl éxito termina aquí
  2. Reintento con backoffSi falla, dead-letter queue y alerta
• CConciliación nocturnaCompara recuentos de Shopify y CRM
  1. Reparar huecosReenvía lo que falta a escritura en CRM

Camino de fallos de una sincronización por webhook: firma, descarte de duplicados, escritura en CRM, reintentos, dead-letter queue y conciliación

Cómo contratar un equipo de integración con Shopify#

Contratar esto es más específico que contratar una agencia web. Quieres un equipo que haya operado sincronizaciones en producción, no uno con un portfolio de tiendas pulidas. Ya busques una agencia de integración de Shopify con HubSpot, un especialista en integración de Shopify con Salesforce o un desarrollador de integración de Shopify con ERP, la evaluación es la misma.

Qué preguntar antes de firmar#

Haz estas ocho preguntas y fíjate en los mecanismos.

• ¿Quién es dueño de las credenciales de la app de Shopify, las claves API del CRM y el workflow o repositorio?
• ¿Cómo evitáis contactos y deals duplicados cuando un evento llega dos veces?
• ¿Qué pasa con los eventos cuando el CRM está caído dos horas?
• ¿Cómo gestionáis el consentimiento de marketing y las bajas en ambas direcciones?
• ¿Cómo son las alertas, quién las recibe y con qué rapidez?
• ¿Cómo cargáis el histórico de pedidos sin chocar con los límites de uso?
• ¿Qué incluye la entrega: documento de mapeo, runbook, accesos, exportación?
• ¿Cuánto cuesta el mantenimiento tras el lanzamiento y qué cubre?

Una buena respuesta nombra un mecanismo: una tabla de IDs de evento, un upsert sobre un ID externo, una dead-letter queue, un informe diario. Una respuesta débil dice "eso lo gestionamos".

Una plantilla breve de SOW#

Incluye estos puntos en el statement of work, una o dos líneas cada uno:

• Sistemas y objetos incluidos, con la tabla de mapeo como anexo
• Dirección y fuente de verdad de cada campo
• Objetivos de volumen y frescura, escritos como números
• Gestión de errores, reintentos y canal de alertas
• Plan de carga histórica y fecha de cutover
• Pruebas de aceptación, ejecutadas contra un sandbox
• Entrega: documentación, accesos, exportación del repositorio o del workflow
• Ventana de soporte tras el lanzamiento y qué cubre

Señales de alerta en las propuestas#

Estas suelen anticipar problemas:

• Ningún documento de mapeo antes de empezar la construcción
• Una tarifa plana sin mención de reintentos ni duplicados
• Ellos guardan las claves API, o crean las cuentas con su propio email
• Sin sandbox, entorno de staging ni plan de pruebas
• Sin monitorización ni alertas tras el lanzamiento
• La promesa de tiempo real para todo

Quién es dueño de la sincronización tras el lanzamiento#

La titularidad tiene tres partes: las cuentas, el código y las alertas. Consigue las tres por escrito antes de la primera factura.

Una sincronización que es tuya puede pasar a otro equipo en días. Una que es suya hay que reconstruirla.

Calendario y coste según el número de integraciones#

El calendario depende más del número de integraciones que del tamaño de la tienda. Los rangos de abajo son ilustrativos, típicos de proyectos como estos, no garantías.

Para el camino recomendado, las fases son estas. Cada integración extra suma su propio mapeo y su propio ciclo de pruebas.

1. Semana 1

   Descubrimiento y mapeo

   Inventario de los sistemas, acuerdo sobre la tabla de mapeo, la fuente de verdad y los objetivos de frescura.

2. Semanas 2 a 3

   Construir la primera sincronización

   Recepción de webhooks, cola, upserts, reintentos y alertas, probados contra un sandbox.

3. Semana 4

   Carga histórica y ejecución en paralelo

   Carga del histórico y comparación de totales con el proceso existente.

4. Semana 5

   Cutover y monitorización

   Cambio en una marca de tiempo registrada y seguimiento de los informes de conciliación.

El mantenimiento forma parte del presupuesto, no es un añadido posterior. Planifica un bloque recurrente de horas para actualizaciones de versión de la API, rotación de credenciales y triaje de alertas, en lugar de una factura sorpresa cuando se retire una versión.

Un CRM, una dirección#

Clientes, pedidos y reembolsos hacia HubSpot o Salesforce suelen llevar de tres a cinco semanas desde el arranque hasta el cutover (ilustrativo). La mayor parte de ese tiempo es el taller de mapeo y las pruebas, no escribir código.

CRM más ERP más email#

Añadir un ERP y una plataforma de email no es sumar. Los sistemas interactúan: el stock y los precios del ERP afectan a lo que muestra el CRM, y el consentimiento tiene que llegar a ambos. Un rango ilustrativo es de ocho a catorce semanas. El ERP es el riesgo habitual, porque los sistemas heredados exponen APIs limitadas o solo exportaciones por lotes. Nuestro artículo sobre integraciones de APIs y sistemas heredados profundiza en ello.

Carga histórica y cutover#

La carga histórica trae el pasado usando operaciones masivas de Admin GraphQL en lugar de recorrer los pedidos de uno en uno. Ejecuta la nueva sincronización en paralelo con el proceso antiguo durante una o dos semanas, compara totales y haz el cutover en una marca de tiempo registrada. Cuando la sincronización principal sea estable, puedes añadir automatización encima, como en nuestro artículo sobre Shopify y automatización con IA.

Cómo construye y monitoriza werun.dev estas sincronizaciones#

Construimos el trabajo de integración de Shopify con CRM con n8n o con una app a medida en Next.js, y elegimos según la lógica y el volumen, no por preferencia. El proceso es el mismo en ambos casos.

Construcción: primero el mapeo, después el código#

La primera semana es un taller de mapeo. El resultado es la tabla, la fuente de verdad de cada campo, las reglas de consentimiento y las pruebas de aceptación. Después construimos contra una development store de Shopify y un sandbox del CRM, con escrituras idempotentes, reintentos y una dead-letter queue desde el primer commit. Nuestro trabajo con Shopify incluye Shopify Plus y operación de tiendas, así que sabemos qué tolera el lado de la tienda.

Monitorización: alertas e informes de conciliación#

Cada sincronización se entrega con alertas a un canal que es tuyo y un informe diario de conciliación: recuentos en ambos lados, discrepancias reparadas y trabajos en espera en la dead-letter queue. Un canal en silencio significa que las cifras coincidieron.

Operación: plan Care o Retainer#

El plan Care cubre el mantenimiento mensual: actualizaciones de versión de la API, rotación de credenciales y triaje de alertas. El Retainer cubre el cambio continuo, como un objeto nuevo o un sistema nuevo. Tú conservas las cuentas y el código. Nosotros tenemos acceso, no custodia. La página del servicio de integraciones enumera lo que conectamos.

Por dónde empezar#

Tres movimientos, en este orden:

1. Inventario. Lista cada sistema que toca a un cliente o un pedido, y qué necesita saber cada uno.
2. Borrador del mapeo. Usa la tabla de arriba, marca la fuente de verdad por campo y escribe los objetivos de frescura como números.
3. Preselecciona dos o tres equipos y envía a cada uno el mismo briefing y las mismas ocho preguntas.

Si quieres una segunda opinión sobre el mapeo o un presupuesto, empieza por nuestra página del servicio de integraciones y cuéntanos qué sistemas usas.

Preguntas frecuentes#