Guía de conectores de Brevo: cuatro formas de conectar Brevo con tu stack
Cómo funcionan de verdad los conectores de Brevo: plugins nativos, iPaaS, una capa de integración o la API directa. Elige el correcto y sobrevive a los fallos de sincronización en producción.
Busca “Brevo connector” y obtendrás una mezcla dispersa de plugins del marketplace, aplicaciones de automatización de terceros y módulos de la comunidad. Eso ocurre porque “conector” no es una sola cosa. Es una categoría que abarca cuatro decisiones de ingeniería genuinamente distintas, cada una con su propio modo de fallo y su propio responsable cuando algo se rompe.
Esta guía define qué es un conector, expone las cuatro opciones con honestidad y luego dedica la mayor parte de su extensión a lo que casi ningún artículo cubre: qué sale mal una vez que el conector está en producción y soportando tráfico real.
Qué es realmente un conector de Brevo
Si quitas la marca, todos los conectores de Brevo tienen los mismos tres componentes.
Transporte. Cómo se mueven físicamente los datos. En la práctica eso significa llamadas a la API REST de Brevo en una dirección y webhooks de Brevo en la otra. Brevo divide los webhooks en tipos de marketing y transaccionales, configurables desde el panel de control o mediante los endpoints de creación y actualización de webhooks, con un techo de 40 webhooks por cuenta entre ambos tipos.
Mapeo. Cómo un campo del sistema de origen se convierte en un campo de Brevo. Un cliente de Shopify tiene first_name; un contacto de Brevo tiene el atributo que hayas definido, y Brevo ignora en silencio los atributos que no existen en tu cuenta. El mapeo es donde la mayoría de los conectores se pudren sin hacer ruido.
Estado. Lo que el conector recuerda entre ejecuciones: qué registros ya ha enviado, cuáles fallaron, en qué posición del cursor se quedó. Los conectores sin estado no pueden recargar históricos, no pueden reintentar un fallo y no pueden decirte si un contacto falta o simplemente llega tarde.
Juzga cualquier conector por lo bien que gestiona los tres. La mayoría de las páginas de marketing solo describen el primero.
El problema del identificador está debajo de todo
El endpoint de creación de contactos de Brevo exige al menos un identificador: email, SMS o ext_id, que es tu propio identificador externo. Por defecto, un identificador en conflicto devuelve un error 4xx. Poner updateEnabled en true convierte la llamada en un upsert, y forceMerge fusiona duplicados conservando el registro con la marca de tiempo más reciente y eliminando el otro.
Esa única decisión de diseño, qué identificador trata tu conector como principal, determina si acabas con una base de contactos limpia o con dos de cada cosa. Decídelo antes de elegir herramienta.
Las cuatro formas de conectar Brevo
Opción 1: plugins nativos y aplicaciones del marketplace
Brevo mantiene un marketplace de aplicaciones que describe como una conexión de Brevo con “más de 150 herramientas digitales como Shopify, WordPress, Stripe, Zapier y más”. Sus aplicaciones propias destacadas son WordPress, WooCommerce, Shopify y BigCommerce, y el marketplace se puede filtrar por categoría y por quién desarrolló la aplicación, algo que importa más de lo que parece: una aplicación construida por Brevo y otra construida por un partner tienen rutas de soporte muy distintas.
Puntos fuertes. El camino más rápido a algo que funciona. La autenticación, el mapeo básico de campos y los eventos habituales vienen precableados. Cuando Brevo cambia su API, el proveedor actualiza el plugin.
Puntos débiles. Te quedas con el mapeo que eligió el proveedor. Los atributos personalizados, los objetos poco habituales y la lógica específica de tu tienda suelen quedarse fuera. La depuración se limita a lo que el plugin registre, que a menudo no es nada útil. Y cuando una aplicación construida por un partner queda abandonada, te enteras durante una caída.
Úsalo cuando tengas una sola plataforma estándar, campos estándar y ninguna necesidad de demostrar qué se sincronizó.
Opción 2: herramientas iPaaS generales
Zapier, Make y Pabbly Connect exponen Brevo. Brevo integra Zapier directamente en su página de integraciones bajo el título “Conecta Brevo con tus aplicaciones, automatiza tu trabajo con Zapier”. Make publica una aplicación de Brevo cuyos módulos cubren observar, crear, actualizar, listar y eliminar contactos, listas, carpetas, campañas, eventos, emails y SMS. Pabbly Connect incluye Brevo entre sus aplicaciones compatibles.
Puntos fuertes. Genuinamente excelentes para la larga cola. Un proveedor de formularios del que nadie ha oído hablar, una herramienta interna puntual, un paso de aprobación que necesita a una persona en medio: el iPaaS resuelve esto en una tarde, y alguien sin perfil técnico puede mantener el escenario.
Puntos débiles. El precio por tarea castiga el volumen. La mayoría de los escenarios van registro a registro, así que una recarga de 40.000 contactos es imposible o cara. La gestión de errores suele ser “la ejecución falló, aquí tienes un email”, sin reintento automático y sin forma de preguntar cuáles de los registros del martes pasado nunca llegaron. El orden no está garantizado, así que una actualización puede adelantar a la creación de la que depende.
Úsalo cuando el volumen sea bajo, el flujo sea unidireccional y perder un registro sea molesto en vez de costoso. Nuestro repaso a las mejores plataformas de integración compara directamente las opciones de esa categoría.
Opción 3: una capa de integración creada para este fin
Una capa que se sitúa entre tus sistemas y Brevo, es propietaria del mapeo y del estado de sincronización, y está construida para este trabajo concreto en vez de para conectar cualquier aplicación con cualquier otra.
Tajo es una de esas opciones. Se describe como un equipo de marketing con AI para Brevo que conecta los datos de comercio compatibles con Brevo, crea segmentos de clientes basados en reglas y prepara campañas de email y SMS con gobernanza. En la práctica, el intercambio de cualquier capa creada para este fin es el mismo: aceptas un modelo con opinión propia sobre contactos, eventos y campañas, y a cambio obtienes recargas históricas, reintentos y visibilidad por registro que ni un plugin ni un iPaaS genérico te dan. Nuestra guía de integración de Brevo recorre la configuración de principio a fin.
Puntos fuertes. Las operaciones masivas son ciudadanas de primera clase. Los fallos son visibles registro a registro y se pueden reintentar. El mapeo es explícito y versionado en vez de estar enterrado en un plugin.
Puntos débiles. Otro proveedor en el camino, y otra cosa que evaluar. Si tu necesidad es un formulario de WordPress publicando en una lista de Brevo, esto es maquinaria pesada para un trabajo pequeño. Sé honesto al respecto: ahí un plugin nativo es la mejor decisión.
Úsalo cuando el volumen de datos de comercio sea real, necesites demostrar qué se sincronizó y quieras segmentos y lógica de campañas construidos sobre el mismo modelo de datos que produce la sincronización.
Opción 4: integración directa con la API
Tu propio código contra la API de Brevo.
Puntos fuertes. Sin techo. Controlas exactamente la resolución de identidad, el agrupamiento, la política de reintentos y el registro de auditoría. Para un almacén de datos que empuja audiencias modeladas hacia Brevo, este suele ser el único enfoque que encaja.
Puntos débiles. Es tuyo para siempre, incluidas las partes que nadie estima: reintentos con backoff, almacenamiento de mensajes fallidos, alertas de deriva de esquema, rotación de credenciales y un manual de operación. Los equipos presupuestan el camino feliz y luego gastan el triple en todo lo demás.
Úsalo cuando la lógica sea genuinamente tuya y el volumen lo justifique. Empieza por nuestra guía de la API de Brevo para el detalle a nivel de endpoint.
El marco de decisión
Seis preguntas lo deciden. Respóndelas antes de mirar ninguna herramienta.
| Pregunta | Plugin nativo | iPaaS | Capa de integración | API a medida |
|---|---|---|---|---|
| Volumen de datos | Lo que admita el proveedor | Bajo, con precio por tarea | Alto, preparado para lotes | Ilimitado |
| Dirección de sincronización | Normalmente unidireccional de entrada | Unidireccional por escenario | Unidireccional con propietarios definidos | Lo que construyas |
| Necesidad de latencia | La que elija el proveedor | Minutos | Casi en tiempo real | La que elijas |
| Complejidad del mapeo | Campos fijos | Sencillo, por escenario | Explícito y versionado | Arbitrario |
| Gestión de errores | A menudo invisible | Alerta al fallar | Reintento y reproducción por registro | Lo que construyas |
| Quién lo arregla | El proveedor del plugin | Tú, en un editor visual | El proveedor, con tu visibilidad | Tú, a las 2 de la mañana |
La última fila es la que la gente se salta y luego lamenta. Un conector es un compromiso operativo a largo plazo, no una tarea de configuración, así que elige la opción cuyo modo de fallo puedas soportar.
Patrones de sincronización que deciden si funciona
Unidireccional frente a bidireccional
La sincronización unidireccional tiene un propietario por campo y es aburrida en el mejor sentido. La bidireccional exige supresión de bucles, resolución de conflictos y una regla de desempate, y Brevo emitirá encantado un webhook contact_updated por un cambio que tu propio conector acaba de escribir.
No construyas sincronización bidireccional porque suene más capaz. Construye en su lugar una tabla de propiedad de campos: tu plataforma de comercio electrónico es dueña de los datos de pedidos, tu CRM del estado del ciclo de vida, Brevo del consentimiento y el engagement. Sincroniza cada campo en una sola dirección. Si de verdad necesitas movimiento bidireccional en un campo, añade un marcador de origen a cada escritura y descarta los eventos entrantes que lleven tu propio marcador.
Sondeo frente a webhooks
Los webhooks son más baratos y rápidos, pero no están garantizados. Los eventos de webhooks de marketing incluyen delivered, opened, click, hard_bounce, soft_bounce, spam, unsubscribe, contact_updated, contact_deleted y list_addition. Los webhooks transaccionales cubren el ciclo de vida del envío, desde sent y delivered hasta deferred, blocked, complaint y error.
Hay dos cosas que planificar. Primero, la documentación de webhooks de Brevo se centra en incluir en lista de permitidos las direcciones IP publicadas por Brevo en vez de en una firma del payload, así que trata el endpoint como no autenticado por defecto y confirma cualquier cosa importante releyendo el registro desde la API. Segundo, ningún sistema de webhooks entrega todo para siempre, así que combina los webhooks con un sondeo de reconciliación de baja frecuencia que recoja lo que se haya escapado.
Lotes frente a tiempo real
El tiempo real importa para los disparadores, y por eso los flujos de carrito abandonado y de bienvenida merecen llamadas de eventos. No importa para una actualización nocturna de atributos.
Ajusta el patrón a los límites de la API. Los endpoints de contactos de Brevo y su endpoint POST /v3/events permiten 10 peticiones por segundo en cuentas estándar, el email transaccional permite 1.000 por segundo y cualquier otro endpoint está limitado a 100 peticiones por hora. Las cuentas Professional y Enterprise aproximadamente duplican el primer grupo. Ese techo de 100 por hora en “el resto de endpoints” es la sorpresa más habitual: un conector que lee listas o carpetas en cada registro lo agotará antes de comer y empezará a recoger respuestas HTTP 429.
Para el trabajo masivo, usa el endpoint de importación en vez de un bucle. Acepta una URL de archivo, el contenido de un archivo o un cuerpo JSON de hasta 10MB con un límite seguro de 8MB, se ejecuta de forma asíncrona, devuelve un processId y llama a una URL de notificación al terminar.
Idempotencia e identidad
El endpoint de eventos de Brevo recibe un event_name, al menos un identificador, propiedades de contacto opcionales y propiedades de evento opcionales de hasta 50KB, y devuelve 204 en caso de éxito. No hay clave de idempotencia documentada, así que una llamada reintentada puede crear un evento duplicado.
Construye tú la idempotencia. Deriva una clave determinista del registro de origen y su versión, guarda qué claves has enviado y comprueba antes de enviar. Para los contactos, elige un identificador principal, rellena ext_id con el ID de tu sistema de origen y usa updateEnabled para los upserts, de forma que un reintento actualice en lugar de dar error.
Diseñar una resincronización en la que puedas confiar
Vas a necesitar resincronizar. Diséñalo desde el primer día.
- Haz que cada escritura sea idempotente, para que reproducirla sea seguro en vez de destructivo.
- Mantén un cursor por tipo de objeto y guárdalo fuera de la memoria del conector.
- Prueba la resincronización contra una lista de Brevo desechable antes que contra la real.
- Deja
emptyContactsAttributesen su valor por defecto, false, durante las importaciones. Ponerlo en true le dice a Brevo que los campos vacíos deben borrar los valores existentes, lo que convierte una exportación parcial en pérdida permanente de datos. - Registra un resultado por registro. “El trabajo terminó bien” no es un resultado cuando 400 de 40.000 registros fallaron la validación.
Qué sale mal de verdad en producción
Deriva del mapeo de campos
Alguien renombra un metacampo de Shopify o añade un campo obligatorio en el checkout. El conector sigue funcionando y sigue informando de éxito, porque Brevo ignora los atributos que no reconoce. Semanas después, un segmento está medio vacío sin que nadie lo note.
Mitigación. Haz una instantánea del esquema de origen y de la lista de atributos de Brevo, compáralas de forma programada y alerta ante cualquier diferencia. Alerta también ante una caída en el porcentaje de valores no nulos por atributo, no solo ante los errores.
Contactos duplicados
La causa clásica son dos conectores con dos identificadores: el plugin de la tienda crea contactos por email, un flujo de SMS los crea por teléfono, y una persona se convierte en dos registros con el historial de engagement partido.
Mitigación. Un identificador principal, aplicado en todas partes. Rellena ext_id desde tu sistema de origen para tener siempre una clave de unión estable. Usa forceMerge como paso deliberado de limpieza, entendiendo que elimina el registro más antiguo, no como un ajuste rutinario.
Bucles de sincronización
El conector A escribe en Brevo, Brevo emite contact_updated, el conector B escribe de vuelta en el origen, el origen emite su propio evento de cambio y el ciclo se repite. Los límites de la API suelen sacar esto a la luz antes de que lo notes tú.
Mitigación. Marcadores de origen en cada escritura, más un contador de cambios por registro que dispare una alarma por encima de un umbral dentro de una ventana temporal.
Límites de la API y fallos parciales
Superar un límite devuelve 429. El caso peligroso no es el 429 en sí, es un lote donde algunos registros tuvieron éxito y otros no, y el conector trata todo el lote como fallido y lo reproduce, o lo trata como correcto y pierde los fallos.
Mitigación. Reintenta con backoff exponencial y jitter, respeta cualquier pista de reintento y registra los resultados por registro en vez de por lote. Envía los fallos a un almacén de mensajes muertos con el payload completo, para poder reproducirlos después de una corrección.
Pérdida silenciosa de datos
Los peores fallos son los silenciosos: una importación con una columna vacía y emptyContactsAttributes en true, un atributo que ya no existe y cuyos valores se evaporan, un endpoint de webhook devolviendo 500 durante una hora sin que nadie mire.
Mitigación. Monitoriza recuentos, no solo errores. Contactos creados al día, eventos recibidos por hora, porcentaje de relleno de atributos. Una métrica que cae a cero es la alerta más clara que vas a tener nunca.
Dos sistemas que no coinciden
Antes o después tu origen dirá 18.400 contactos activos y Brevo dirá 18.062. Sin reconciliación no puedes saber cuál tiene razón.
Mitigación. Ejecuta una reconciliación programada que compare recuentos y una muestra de registros por identificador, y genera un informe de diferencias. Corrige las causas en vez de reimportar una y otra vez, porque una reimportación oculta el desajuste sin explicarlo.
Conexiones habituales en la práctica
Comercio electrónico. Shopify y WooCommerce son los dos pesos pesados, y ambos tienen aplicaciones propias en el marketplace de Brevo. El camino nativo gestiona bien los contactos y los datos básicos de pedidos. La lógica personalizada de líneas de pedido, el estado de las suscripciones y los niveles de fidelización normalmente no encajan, y ahí es donde una capa o el código a medida se ganan su sitio. Nuestra guía de integración de Brevo con Shopify cubre esa combinación concreta en profundidad.
CMS. WordPress es la conexión con Brevo más habitual fuera del comercio electrónico, normalmente para formularios, altas de newsletter y email transaccional a través del SMTP de Brevo. Aquí el camino del plugin casi siempre es el correcto, ya que el modelo de datos es simple y el volumen es bajo.
CRM y almacén de datos. Aquí es donde los conectores se ponen difíciles, porque ambos lados creen ser dueños del cliente. Usa una tabla de propiedad de campos, sincroniza en una sola dirección por campo y plantéate empujar audiencias modeladas desde el almacén hacia listas de Brevo en vez de sincronizar registros en crudo. Consulta nuestra guía del CRM de Brevo para ver cómo encajan en ese cuadro los propios objetos de CRM de Brevo.
Formularios. El caso de uso ideal para un iPaaS: volumen bajo, una dirección, tolerante a la latencia. No lo sobrediseñes.
Cómo acertar
La elección de conector es sobre todo una cuestión de operaciones, no de funcionalidades. Todas las opciones pueden mover un contacto de A a B. Se diferencian en lo que pasa el día en que el mapeo se desvía, salta el límite de la API o 400 registros fallan la validación dentro de una importación de 40.000.
Recórrelo en este orden:
- Escribe qué sistema es dueño de qué campo. Todo lo demás se deriva de esto.
- Elige un identificador de contacto principal y rellena
ext_iddesde tu sistema de origen. - Elige la opción más ligera que sobreviva a tu volumen y a tu requisito de gestión de errores, no la más capaz.
- Construye la resincronización y el informe de reconciliación antes de salir a producción, no después del primer incidente.
- Monitoriza recuentos y porcentajes de relleno, porque la pérdida silenciosa es más común que el fallo ruidoso.
Haz esas cinco cosas y cualquiera de los cuatro enfoques puede funcionar. Sáltatelas y ninguno funcionará.