Intégrations Brevo : choisir une connexion vérifiable

Envoyez deux fois le même contact de test. Si le second passage crée une autre fiche ou réactive un désabonnement, la connexion échoue avant même de traiter du volume. « Il suffit de relier les applications » décrit le départ, mais pas ce que la connexion mémorise après la première requête.

Vérifier trois éléments avant de choisir

Le transport transmet une requête ou un événement. Le mapping définit le sens des champs. L’état conserve la version source traitée, les échecs et la fiche de destination associée. Notez une source, une destination et les champs du premier résultat utile. Désignez un propriétaire pour chaque champ : le CRM peut gérer l’étape commerciale, tandis que Brevo détient le désabonnement e-mail actuel.

Quatre chemins vers Brevo

Application native

Cherchez une application maintenue et son éditeur sur la marketplace Brevo. Vérifiez les champs et événements nécessaires dans sa documentation. La présence sur la marketplace ne prouve aucune intégration Tajo. Pour Shopify, commencez par le parcours Brevo PushOwl documenté et testez son mapping avant d’ajouter une seconde connexion. Les possibilités de reprise dépendent de l’application choisie.

Service d’automatisation

Un service peut recevoir un formulaire, mapper les champs et appeler Brevo. Vérifiez les reprises réelles, les coûts par tâche et le stockage. Un faible volume ne rend pas acceptable une inscription perdue. Notre guide Webflow distingue le formulaire Brevo intégré du formulaire natif traité côté serveur. Choisissez celui qui préserve soumission et confirmation.

Couche d’intégration

Une couche dédiée se justifie quand plusieurs mappings, un suivi durable ou une récupération coordonnée l’exigent. Demandez une démonstration d’une fiche rejetée puis rejouée. Le nom de la catégorie ne prouve pas cette fonction. Tajo est en accès anticipé : apportez source, destination et critère de validation à une revue d’intégration. Vérifiez le connecteur disponible et son exécution avant d’en dépendre. Une page sur une paire d’applications n’établit pas sa disponibilité dans votre espace.

Code API direct

Choisissez le code si les autres chemins ne couvrent pas l’identité, la transformation ou la récupération requise. Votre équipe gère alors identifiants, limites, état et procédure d’exploitation. Consultez le guide API Brevo pour l’écriture d’un contact. L’exemple Apps Script fournit un chemin distinct pour un tableur, sans connecteur Sheets natif de Tajo.

Choisir selon le besoin réel

Critère	Application native	Automatisation	Couche d’intégration	API directe
Champs	Vérifier le mapping	Vérifier les entrées	Examiner le mapping	Le coder
Identité	Vérifier la correspondance	La configurer	Examiner le contrat	Garder l’ID cible
Récupération	Examiner les contrôles	Tester les reprises	Exiger une démonstration	La construire
Limites	Confirmer celles du fournisseur	Estimer tâches et limites	Tester la charge	Respecter les limites
Responsable	Éditeur et opérateur	Responsable du scénario	Fournisseur et responsable sync	Votre équipe

Quel chemin couvre votre exigence réelle ?

1. L’application native couvre champs et contrôles

   Utiliser l’application native

   Commencer par la configuration documentée.

2. Un formulaire exige une petite action mappée

   Évaluer l’automatisation

   Vérifier confirmation et rejeu.

3. Plusieurs mappings demandent une reprise coordonnée

   Évaluer une couche d’intégration

   Faire démontrer échec et rejeu.

4. La transformation nécessaire manque

   Écrire le plus petit chemin API

   Prévoir aussi son exploitation.

Prouver la première synchronisation sur une fiche

Utilisez une destination isolée et un contact que vous contrôlez. Désactivez les automatisations de campagne pendant le contrôle.

1. Notez ID source, liste cible, attributs obligatoires et preuve actuelle du consentement. Créez les types d’attribut avant l’écriture.
2. Exécutez une fois et inspectez la fiche cible, pas seulement le statut du job. Vérifiez valeurs et éligibilité marketing séparément.
3. Rejouez la même version source : une seule identité, sans nouveau message de confirmation ou de bienvenue.
4. Modifiez un champ, puis laissez un autre vide. Vérifiez la règle documentée de conservation ou d’effacement.
5. Enregistrez un désabonnement ultérieur. Rejouez l’ancienne inscription : le désabonnement doit prévaloir.
6. Simulez un rejet. Gardez son identité et son résultat, récupérez cette fiche et inspectez-la avant d’avancer le curseur.

Ce protocole ne promet pas les mêmes contrôles pour tous les connecteurs. Une étape impossible à démontrer révèle une exigence encore non satisfaite.

Reprises, limites et effets secondaires

L’endpoint de contact Brevo accepte ext_id et updateEnabled, mais vous restez responsable du rapprochement. Des identifiants contradictoires exigent examen ; forceMerge peut supprimer une fiche et ne doit pas être le réglage normal de récupération. Une fiche unique peut quand même recevoir deux e-mails de confirmation. Gardez l’ID de soumission et le résultat de chaque effet. Après un délai dépassé, inspectez la cible avant de renvoyer. Lisez les limites actuelles par endpoint et forfait : les plafonds horaires et par seconde varient.

Les webhooks ont aussi besoin d’un responsable

Un événement signale un changement, sans résoudre les propriétaires de champs ni maintenir à lui seul un flux bidirectionnel.

Authentifiez la livraison selon le fournisseur, conservez le travail valide et réconciliez les mises à jour manquées. Si le connecteur reçoit sa propre écriture, comparez version source et valeurs prévues avant de réécrire. Ne supposez pas un marqueur d’origine universel. Pour un nouvel abonné, suivez le guide du double opt-in avant l’ajout à une audience marketing. Une adresse copiée et une adresse confirmée actuellement abonnée sont deux résultats différents. La connexion est prête quand le deuxième passage s’explique aussi bien que le premier.