À la fin de ce tutoriel, vous saurez repérer les entreprises lemlist dont la synchronisation avec le CRM est bloquée par un domaine en doublon. Vous saurez rattacher leurs contacts à la bonne fiche et automatiser toute la procédure avec l’API lemlist, sans aucune intervention manuelle dans l’interface lemlist.

Lorsque des contacts ne peuvent pas se synchroniser avec votre CRM, votre équipe commerciale travaille avec des données incomplètes. Des opportunités restent sans suivi, des comptes restent invisibles dans HubSpot, Salesforce ou Pipedrive, et les lacunes du pipeline passent inaperçues : aucune erreur n’est signalée aux commerciaux. UNIQUE_INDEX_ERROR_COMPANY est l’une des causes les plus fréquentes de ce problème. Pour les équipes qui gèrent de grandes bases de contacts, cette erreur peut bloquer des centaines de fiches à la fois, sans qu’elles s’en aperçoivent.

Cette erreur se produit parce que lemlist utilise le domaine de l’entreprise comme identifiant unique lors de la synchronisation. Si deux entreprises lemlist partagent le même domaine, seule la première à se synchroniser y parvient. Tous les contacts rattachés à la seconde restent bloqués tant que vous n’avez pas résolu le conflit.

lemlist n’enregistre plus les domaines d’adresses email personnelles (gmail.com, yahoo.com, outlook.com et ceux d’autres fournisseurs d’email courants) comme domaines d’entreprise. Les nouvelles entreprises ne sont donc plus créées avec l’un de ces domaines. Les entreprises créées à partir d’un domaine personnel avant ce changement ne sont pas mises à jour rétroactivement : cette procédure reste valable pour elles.

Sans accès à l’API, la seule solution consiste à ouvrir chaque doublon dans l’interface lemlist et à le corriger manuellement, un par un. Les trois routes de l’API présentées dans ce tutoriel permettent d’automatiser toute la procédure et d’en planifier l’exécution, pour résoudre les nouveaux conflits avant même que votre équipe ne les remarque.

Si la répercussion des fusions du CRM est activée dans votre espace de travail, fusionner deux entreprises dans HubSpot ou Salesforce entraîne automatiquement leur fusion dans lemlist. Les contacts, l’historique, les tâches, les inscriptions aux campagnes et les listes de l’entreprise en doublon sont transférés vers celle qui est conservée, puis le doublon est supprimé. Le nettoyage dans votre CRM suffit alors : cette procédure n’est pas nécessaire.

Ce tutoriel reste utile dans les cas suivants :

La répercussion des fusions est déployée progressivement et n’est pas encore activée sur tous les espaces de travail. En cas de doute pour votre espace de travail, contactez l’équipe support.

La procédure repose sur trois routes de l’API. Avant de créer votre automatisation, prenez quelques minutes pour comprendre ce que renvoie chacune d’elles : la phase 2 sera plus facile à suivre.

Le nouveau paramètre de requête crmSyncStatus permet de filtrer les entreprises selon leur état de synchronisation. Utilisez la valeur unique_index_error_company pour ne récupérer que les entreprises bloquées par un conflit de domaine.

Autres valeurs acceptées pour crmSyncStatus : synced, not_synced, error, property_doesnt_exist, required_field_missing, company_already_exists_with_name, company_already_exists_with_linkedin_url.

Chaque entreprise renvoyée dans la réponse comprend désormais un bloc crmSync :

alreadyExistingCompanyId est l’identifiant de l’entreprise lemlist déjà synchronisée avec le CRM pour ce domaine. C’est à elle que vous rattacherez les contacts à l’étape 3.

💡 Ce champ vous évite d’avoir à deviner quelle entreprise est la bonne. L’API vous l’indique directement : c’est celle qui se synchronise déjà avec votre CRM.

Quatre nouveaux filtres permettent de lister tous les contacts rattachés à une entreprise donnée. Vous ne pouvez en utiliser qu’un à la fois :

Pour les filtres par domaine ou par URL, l’API recherche en interne le companyId correspondant. Si aucune correspondance n’est trouvée, elle renvoie une liste vide, et non une erreur 404.

💡 Ces filtres sont aussi utiles en dehors de la suppression des doublons. Si vous faites de la prospection ciblée par compte, vous pouvez récupérer tous les contacts associés au domaine d’une entreprise sans connaître son identifiant interne.

Cette route supprime une fiche d’entreprise dans lemlist. Si des contacts y sont encore rattachés, la requête est refusée avec une erreur 400 COMPANY_HAS_CONTACTS qui inclut contactCount.

Ajoutez ?force=true pour détacher tous les contacts rattachés à l’entreprise avant de la supprimer. Le champ companyId de ces contacts n’est alors plus défini. La réponse contient unlinkedContacts : N, qui confirme le nombre de contacts détachés. Utilisez cette option lorsque les contacts n’ont pas besoin d’être rattachés à une autre entreprise, par exemple si le doublon contenait des fiches de test ou des contacts que vous ne souhaitez pas conserver.

Maintenant que vous connaissez le rôle de chaque route, enchaînez les appels dans l’ordre ci-dessous. Ces quatre appels à l’API résolvent automatiquement tous les conflits de doublons. Exécutez-les manuellement pour un nettoyage ponctuel, ou programmez leur exécution chaque nuit dans n8n, Zapier ou Make.

Pour chaque résultat, extrayez deux valeurs de l’entreprise renvoyée :

Vous disposez maintenant de deux identifiants par conflit : celui de l’entreprise à supprimer et celui de l’entreprise à laquelle rattacher les contacts. Un seul appel à l’API suffit pour obtenir ces informations pour toutes les entreprises bloquées de votre espace de travail.

Cet appel renvoie tous les contacts actuellement rattachés à l’entreprise en doublon.

Avant de les rattacher à une autre entreprise, vous devez disposer de la liste complète des contacts concernés. Faites cet appel une fois pour chaque entreprise bloquée repérée à l’étape 1 : parcourez les résultats et récupérez tous les contacts à déplacer.

Pour chaque contact renvoyé à l’étape 2, utilisez son adresse email pour le créer ou le mettre à jour, en renseignant companyId avec l’identifiant de la bonne entreprise :

Chaque contact est ainsi rattaché à l’entreprise qui se synchronise déjà avec votre CRM. Il appartient alors au bon compte et sera synchronisé au prochain cycle de synchronisation avec le CRM.

Une fois tous les contacts rattachés à la bonne entreprise, le doublon n’a plus aucune fiche rattachée et peut être supprimé sans blocage. Le conflit de domaine est ainsi résolu : les prochaines synchronisations de la bonne entreprise s’effectueront sans erreur. Si vous n’avez pas effectué l’étape 3, utilisez ?force=true pour détacher les contacts et supprimer le doublon en un seul appel. Les contacts détachés ne seront toutefois associés à aucune entreprise tant que vous ne les aurez pas réaffectés.

Voici un exemple concret : l’équipe RevOps d’une entreprise SaaS B2B découvre que plus de 200 contacts manquent dans HubSpot. Après avoir consulté les journaux de synchronisation dans Paramètres → Intégrations → HubSpot → Journaux, elle repère 14 entreprises qui présentent l’erreur UNIQUE_INDEX_ERROR_COMPANY. Toutes partagent leur domaine avec des entreprises déjà présentes dans le CRM, à la suite d’un import de données en masse réalisé plusieurs mois auparavant.

Plutôt que d’ouvrir les doublons dans l’interface lemlist et de les corriger un par un, ce qui lui aurait pris une bonne partie de la journée, l’équipe met en place une automatisation n8n en quatre étapes :

La première exécution résout les 14 conflits et débloque tous les contacts concernés, soit plus de 200. Ils apparaissent dans HubSpot au cycle de synchronisation suivant. L’équipe programme ensuite une exécution chaque nuit. Au cours des deux semaines suivantes, l’automatisation détecte et résout automatiquement trois nouveaux conflits, qui seraient passés inaperçus jusqu’à ce qu’un commercial signale des données manquantes.

Cause : des contacts sont encore rattachés à l’entreprise. L’étape 3 n’a pas été exécutée ou n’a pas abouti pour tous les contacts.

Cause : il s’agit d’un autre type de conflit. Ce champ n’apparaît que pour unique_index_error_company ; les autres motifs d’erreur ont des métadonnées différentes.

Cause : le contact est peut-être rattaché à une autre entreprise qui présente elle aussi des erreurs de synchronisation, ou le CRM a peut-être besoin de quelques minutes pour terminer le traitement.

Cause : DELETE /api/companies supprime uniquement la fiche dans lemlist, sans modifier votre CRM.