By the end of this tutorial, you'll know how to identify lemlist companies blocked from CRM sync by a duplicate domain conflict, remap their contacts to the correct record, and automate the full cleanup workflow using the lemlist API — without any manual work in the lemlist UI.

When contacts can't sync to your CRM, your sales team works with incomplete data. Deals go unfollowed, accounts are invisible in HubSpot, Salesforce, or Pipedrive, and pipeline gaps are silent — no error surfaces to the rep. UNIQUE_INDEX_ERROR_COMPANY is one of the most common causes of this, and for teams with large contact databases it can silently block hundreds of records at once.

The error occurs because lemlist uses company domain as a unique identifier when syncing. If two lemlist companies share the same domain, only the first one to sync succeeds. Every contact linked to the second is blocked until you resolve the conflict.

Without API access, the only fix is manual — opening each duplicate in the lemlist UI and correcting it one at a time. The three endpoints in this tutorial let you automate the entire process and run it on a schedule, so new conflicts are resolved before your team ever notices them.

Three endpoints do the work. Before building your automation, take a few minutes to understand what each one returns — it'll make Phase 2 much clearer.

The new crmSyncStatus query parameter filters companies by their sync state. Pass unique_index_error_company to return only companies blocked by a domain conflict.

Other accepted values for crmSyncStatus: synced, not_synced, error, property_doesnt_exist, required_field_missing, company_already_exists_with_name, company_already_exists_with_linkedin_url.

Each company in the response now includes a crmSync block:

The alreadyExistingCompanyId is the lemlist company already occupying the conflicting CRM slot — this is the company you will remap contacts to in step 3.

💡 This field does the hard thinking for you. Instead of guessing which company is the correct one, the API tells you directly — it's the one already syncing to your CRM.

Four new mutually exclusive filters let you list all contacts attached to a given company. Pass any one of them:

The domain and URL variants resolve to a companyId internally. If no match is found, the endpoint returns an empty list — not a 404.

💡 These filters are also useful beyond duplicate cleanup: any team running account-based outreach can use them to pull all contacts for a given company domain without needing to know the internal ID.

Deletes a lemlist company record. If contacts are still attached, the request is refused with a 400 COMPANY_HAS_CONTACTS error that includes a contactCount.

Pass ?force=true to detach all attached contacts before deletion. Detached contacts have their companyId unset. The response includes unlinkedContacts: N confirming how many were detached. Use this when contacts don't need to be remapped — for example, if the duplicate contained test records or contacts you don't want to preserve.

Now that you know what each endpoint does, chain them together in sequence. These four API calls resolve every duplicate conflict automatically. Run them manually for a one-time cleanup, or schedule them nightly in n8n, Zapier, or Make.

For each result, extract two values from the crmSync block:

You now have two IDs per conflict: the company to delete and the company to remap contacts to. A single API call gives you the full picture for every blocked company in your workspace.

This returns all contacts currently linked to the duplicate company.

Before remapping, you need a complete list of who's affected. Run this once per blocked company from step 1 — loop through each result and collect all the contacts to move.

For each contact returned in step 2, upsert by email and set companyId to the correct company:

Remapping assigns each contact to the company already syncing to your CRM. After this step, the contact belongs to the correct account and will sync on the next CRM cycle.

With all contacts remapped, the duplicate has no attached records and can be removed cleanly. This resolves the domain conflict — future syncs for the correct company will complete without errors. If you skipped step 3, use ?force=true to detach and delete in one call, but note that detached contacts will have no company associated until you reassign them.

Here's what this looks like in practice. A B2B SaaS company's revenue operations team discovers that over 200 contacts are missing from HubSpot. After checking sync logs in Settings → Integrations → HubSpot → Logs, they find 14 companies flagged with UNIQUE_INDEX_ERROR_COMPANY — all sharing domains with companies already in their CRM following a bulk data import several months prior.

Instead of opening each duplicate in the lemlist UI and correcting it one at a time — which would have taken the better part of a day — they build a four-step n8n workflow:

The first run resolves all 14 conflicts and unblocks all 200+ contacts, which appear in HubSpot within the next sync cycle. They schedule the workflow to run nightly. Over the following two weeks, it automatically catches and resolves three new conflicts — none of which the team would have noticed until a rep flagged missing data.

Root cause: Contacts are still attached — step 3 didn't run or didn't complete for all contacts.

Root cause: The conflict type is different. This field only appears for unique_index_error_company — other error reasons have different metadata.

Root cause: The contact may be linked to a different company that also has sync errors, or the CRM may need a few minutes to process.

Root cause: DELETE /api/companies only removes the lemlist record — it does not modify your CRM.