Conexiones que
funcionan a la perfección

indigitall se integra con HubSpot, Salesforce Marketing Cloud, Salesforce Service Cloud, Shopify, VTEX IO, WordPress y WhatsApp mediante guías publicadas en su documentación, y con cualquier otro sistema mediante API REST, SDK, webhooks y carga de archivos CSV. En cada conector la documentación indica hacia dónde viaja el dato: de HubSpot, de Salesforce Marketing Cloud y de Shopify hacia indigitall, y de indigitall hacia tu sistema cuando se dispara un webhook. La tabla de abajo muestra, sistema por sistema, la dirección del dato, el evento, los canales, los identificadores y lo que la guía todavía no detalla.

• Conectores con guía publicada: HubSpot, Salesforce Marketing Cloud, Salesforce Service Cloud, Shopify, VTEX IO, WordPress y WhatsApp.

• Vías para cualquier otro sistema: API REST, SDK, webhook y carga de archivos CSV.

• Datos que debes preparar: un identificador único de tu CRM, teléfono y código de país para SMS, email para correo, deviceId cuando uses push y customerId para una carga CSV en Customer Journey. externalCode y externalId son identificadores que indigitall genera o utiliza internamente para unificar los datos.

• Acceso: Server Key con roles por proyecto y lista blanca de IP; usuarios con rol de Administrador o de Usuario.

Esta página es para el equipo de TI, de CRM o de marketing operations que necesita saber, antes de la primera reunión, si indigitall se conecta con su plataforma actual y en qué dirección viaja cada dato. Quien la lee sale con la tabla de conectores, los identificadores que debe preparar y la lista de lo que conviene confirmar con el equipo de indigitall antes de planear el proyecto.

En HubSpot instalas la app de indigitall desde el App Marketplace, autorizas el acceso a los datos del CRM e inicias sesión en la consola de indigitall con credenciales de administrador. Después puedes agregar acciones de indigitall (push de app o web, SMS, email o WhatsApp) en cualquier paso de un workflow. Cada acción pide el ID de la campaña creada antes en la consola y el identificador del destinatario: en push, deviceId o externalCode (la guía recomienda externalCode porque simplifica la integración) y, en SMS, el campo de teléfono con el código de país. Los parámetros de la campaña se llenan con propiedades del contacto, por ejemplo teléfono, email o campos personalizados. La guía distingue los errores que bloquean la acción de las advertencias que afectan solo a algunos usuarios. El flujo documentado va de HubSpot hacia indigitall. Los pasos completos están en la documentación de HubSpot de indigitall.

Un contacto llena un formulario en HubSpot y entra a un workflow. El workflow ejecuta una acción de indigitall que lanza una campaña de WhatsApp con el nombre del contacto como parámetro.

Creas en Journey Builder actividades personalizadas de indigitall para push, chat de WhatsApp y SMS, y cada una apunta a un endpoint del conector. Primero agregas un paquete en Salesforce Marketing Cloud y tomas su Client ID, su Client Secret (solo se muestra al generarlo), su Authentication Base URI y su MID; de indigitall necesitas la App Key del proyecto y una Server Key. Hay una restricción que conviene conocer desde el inicio: una actividad de Journey Builder carga un solo applicationId. Además, indigitall no procesa datos por subscriberKey sino por externalId, así que eliges qué campo de la extensión de datos aporta el externalId de cada contacto. Las estadísticas de push regresan a una extensión de datos con ocho campos: ConversationId, Action (New o Click), ContactKey, UniqueCampaignLabel, ButtonClicked, ActionDate, DeviceId y LatestRecord. Guía completa en la documentación de Salesforce Marketing Cloud de indigitall.

Un contacto entra a un journey en Journey Builder y llega a una actividad personalizada de indigitall que envía un push o un mensaje de WhatsApp. Después, la acción de envío o de clic del push se registra en una extensión de datos de Salesforce.

La guía de Service Cloud usa Canvas, el mecanismo de Salesforce para embeber una aplicación web existente dentro de su consola. La configuración tiene seis pasos: crear una Connected App en Setup, configurar Canvas con la URL de autenticación y el método de acceso, autorizar a los usuarios por perfil, desarrollar un Lightning Web Component que referencie el API Name de la app, agregarlo a una página con Lightning App Builder y activarlo para los usuarios elegidos. Requiere cualquier edición de Salesforce, una URL de la aplicación accesible públicamente y OAuth habilitado. La propia guía aclara que no entra en la gestión de eventos ni en el contexto de Salesforce y no detalla canales ni la dirección del dato, así que conviene definir con el equipo de indigitall qué conversaciones se verán dentro de Service Cloud antes de planear el proyecto. Consulta la guía de Salesforce Service Cloud.

Al activar el conector, indigitall escucha eventos de comportamiento de tu tienda Shopify. Los identificadores por defecto son login, productView, addToCart, purchase, checkoutStarted y searchSubmitted, y puedes renombrarlos con alias para alinearlos con tus flujos. En la configuración eliges qué campos del cliente de Shopify sincronizar, los mapeas a campos personalizados de indigitall (puedes crear uno nuevo en ese momento) y decides qué eventos recolectar. Cada evento lleva datos del cliente y de la operación en customData; la compra completada, por ejemplo, incluye totales, direcciones y artículos. Para instalar la app necesitas una cuenta de indigitall y acceso al panel de Shopify. La guía de la app contiene además una nota que indica que el retargeting no está soportado actualmente, aunque conserva pasos antiguos de configuración (que piden el banner de cookies activo); su estado no está confirmado. Los nombres de indigitall son propios: Shopify publica los suyos, como product_viewed y checkout_started, en la documentación de eventos estándar de su Web Pixels API. Guías de indigitall: Shopify y Shopify Customer Events.

Un cliente agrega un producto al carrito en la tienda. indigitall recibe el evento addToCart con los datos del producto en customData y, si el cliente inicia el pago, recibe checkoutStarted. indigitall registra esos eventos con los campos que mapeaste en la configuración.

La guía de VTEX IO documenta la instalación de web push en siete pasos: descargar los archivos del SDK de indigitall, subir service-worker.js (con el contenido de worker.min.js) y sdk.min.js con esos nombres exactos en el editor de código de VTEX, desactivar el service worker predeterminado de VTEX para evitar conflictos y agregar el código de inicialización con Google Tag Manager o con una implementación web estándar. VTEX IO es la plataforma de desarrollo low-code de VTEX para aplicaciones empresariales: permite construir tiendas web, aplicaciones de administración e integraciones de backend. La guía de indigitall no publica eventos ni campos de ecommerce para VTEX y no describe un flujo general de datos de la tienda hacia indigitall; si necesitas enviar datos de ecommerce desde VTEX IO, ese alcance no está descrito en la guía revisada y debe definirse como una integración aparte. Consulta la guía de VTEX IO.

El plugin gratuito de indigitall se instala desde el panel de WordPress: Plugins, Agregar nuevo, buscar indigitall, instalar, activar y configurar. Activa un chat de WhatsApp en el sitio, con los colores de tu marca y un mensaje inicial configurable, y permite configurar web push dentro del plugin o desde la consola de indigitall para acceder a las funciones avanzadas. Los pasos están en la guía del plugin de WordPress.

La conexión se hace desde la consola de indigitall con el registro integrado de Meta: entras a la configuración de Chat v2, inicias sesión con Facebook, registras el número con su código de país, verificas el código de seis dígitos, eliges o creas el portafolio de negocio y la cuenta de WhatsApp Business (WABA), revisas los permisos y esperas a que Meta cambie el estado del número de Pendiente a Conectado. Necesitas acceso de administrador al portafolio de negocio de Meta, un número que no esté registrado en la app de WhatsApp y el servicio Chat v2 activo en el proyecto. La Cloud API de WhatsApp Business Platform de Meta entrega los mensajes entrantes y las actualizaciones de estado como webhooks en JSON a un endpoint público. La guía completa tiene once pasos: conexión de un número de WhatsApp.

Cuando tu sistema (un CRM, un ERP u otro) no tiene un conector en la tabla, las vías documentadas son la API REST, los SDK (Android, iOS, web, Flutter, React Native y Cordova) y la carga de archivos CSV. La guía de sincronización de datos describe el modelo: eliges un identificador único de cada cliente en tu CRM, por ejemplo el teléfono o el email, y con la API o el SDK lo mueves a la consola, donde se genera internamente un identificador cifrado llamado externalCode o externalId. En push, además, se necesita el deviceId de cada dispositivo; en Customer Journey, el identificador único se llama customerId. La guía precisa que la integración por API o SDK la hace el equipo de TI del cliente, que por API los datos se sincronizan en tiempo real y que indigitall no mueve información por su cuenta. La API y los SDK permiten enviar datos a indigitall y operar recursos según el endpoint; no deben interpretarse como una sincronización bidireccional general con el CRM. Para ver cómo se unifican esos datos en un perfil de cliente, consulta la plataforma de datos de clientes (CDP) de indigitall, que según su página reúne web, app, WhatsApp, SMS, voz y tienda en un único perfil en tiempo real. Los detalles están en la guía de sincronización de datos.

La API REST sirve para que tu sistema llame a indigitall: contactos, campañas, customer journeys, mensajes, segmentación y estadísticas. La referencia vigente es la API v2, y la v1 se mantiene por compatibilidad con integraciones antiguas. El webhook funciona al revés: un evento de un customer journey hace que indigitall llame a una URL tuya. Al crear la plantilla defines el nombre, la URL, el método HTTP (POST, GET, PUT u otro), un cuerpo JSON con variables como {{customer.phone}} y, si lo necesitas, encabezados opcionales, por ejemplo Authorization con un Bearer token. La guía de webhook no documenta firma de las solicitudes, reintentos ni un catálogo de eventos, así que conviene acordarlos con el equipo de indigitall.

Las integraciones por API usan una Server Key, una API key que se genera en Settings > Server Keys de la consola; se puede asignar con un rol al proyecto completo o a proyectos específicos y limitar con una lista blanca de direcciones IP. Los usuarios de la consola tienen dos roles: Administrador, con acceso completo a la cuenta, y Usuario, con permisos por proyecto en tres niveles: Read para ver estadísticas y campañas, Write para además crear y enviar campañas, y Manage para editar audiencias y herramientas. Sin un permiso explícito sobre el proyecto, un usuario no puede entrar a él. La guía de sincronización de datos indica que los datos transmitidos y almacenados están cifrados por indigitall, y la documentación pública de seguridad de indigitall identifica SOC 2 Type II como una certificación basada en una auditoría independiente de la plataforma SaaS de marketing automation; ISO/IEC 27001:2022 y ENS HIGH como certificaciones aplicadas a los servicios o sistemas SaaS de marketing automation; GDPR/LOPDGDD como una verificación externa; HIPAA como una auditoría del servicio de notificaciones push cifradas; y BAA HIPAA ready como la capacidad declarada para firmar BAAs. Confirma cuál aplica a tu producto, canal y región. Guías: Server Keys y usuarios y permisos.

En la consola, Estadísticas > Push muestra enviados (envíos brutos sin contar errores), notificaciones recibidas y CTR, la proporción de clics sobre los enviados, con separación entre web y app, filtros por fecha y por categoría de campaña, y descarga en CSV, según la guía de estadísticas de push. Para medir fuera de indigitall, agregas parámetros UTM fijos o dinámicos a las notificaciones push de app y web, como describe la guía de reportes, y analizas el resultado en tu herramienta de analítica; Google Analytics documenta cómo se usan utm_source, utm_medium y utm_campaign. Con Salesforce Marketing Cloud, las acciones de envío y clic de push se registran en una extensión de datos de Salesforce. Por API, algunos endpoints devuelven estadísticas en JSON, CSV o ZIP, según el endpoint. Y para consultarlas desde un asistente de IA, el conector MCP de indigitall es de solo lectura: según su página, no envía campañas ni cambia configuraciones.

Son los puntos que las guías publicadas no cierran, y conviene dejarlos escritos en el alcance antes de firmar:

• Sincronización en ambos sentidos. Las guías describen flujos concretos, como los de la tabla, y una sincronización general en ambos sentidos no consta en ellas; si tu proyecto la necesita, defínela como requisito.
• Carrito abandonado en retail y ecommerce. En Shopify, la guía de la app contiene una nota que indica que el retargeting no está soportado actualmente, aunque conserva pasos antiguos de configuración, así que su estado no está confirmado; en VTEX IO, la guía documenta web push sin eventos de carrito.
• Webhook. La guía no publica firma de las solicitudes, reintentos ni catálogo de eventos.
• Límites y frecuencia. No se publican límites de tasa en la referencia de la API consultada.
• Otros sistemas. La ficha de partners de la documentación lista los conectores con guía; para cualquier sistema que no esté ahí, la vía documentada es la API, el SDK o el CSV, con trabajo de tu equipo de TI.
• Ubicación y retención de datos. La política de seguridad pública no detalla la ubicación física de los servidores ni los períodos de retención; pídelos por escrito al equipo de indigitall.