Skip to main content
This error appears when the identifiers you pass during an import or an edit operation belong to different customers. Because Maestra cannot tell which existing profile you mean, it refuses to apply the change instead of guessing.

​
Why the error happens

Every customer in Maestra is described by a set of identifiers — website ID, CRM ID, email, phone, loyalty card number, and so on. When you send an operation (import, edit, event, subscription change) that carries more than one identifier, Maestra looks each one up and expects them all to resolve to the same profile. If one identifier already belongs to Customer A and another to Customer B, there is no single target for the change. Maestra cannot uniquely identify the customer, so it rejects the operation and returns this error.
Often one of the conflicting identifiers is no longer the customer’s current value — it sits in the change history of another profile. Checking the change history on each profile is usually the fastest way to spot the conflict.

​
Example

You have two existing customers:
CustomerIdentifier
Customer 1WebsiteID 111111
Customer 2CrmID 222222
You then send an import row that combines identifiers from both:
FieldValue
WebsiteID111111
CrmID222222
Emailmail1@mail.ru
Maestra cannot decide whether to attach mail1@mail.ru to Customer 1 or Customer 2. No data is written, and the operation fails with “Cannot uniquely identify the customer.”

​
How to diagnose it

1

Open the change history on each profile

Pull up both customers that match the identifiers in the failing record and review their change history. Look for an identifier that used to live on one profile and now appears on the other — that is usually where the collision started.
2

Compare the identifiers in the failing payload

List every identifier in the import row or edit request and check each one against the customer profile it resolves to. If two identifiers resolve to two different profiles, you have found the conflict.
3

Decide which profile is correct

Confirm with the source system (your website, CRM, POS, etc.) which customer the record should belong to. Only then can you clean up the identifier that does not belong there.

​
How to fix it

Before you retry the operation, make sure every identifier in the payload points to the same customer profile. Depending on the situation, that may mean:
  • Removing the stray identifier from the import row so only identifiers for one customer are sent.
  • Updating the customer profile that holds the outdated identifier so it no longer conflicts.
  • Merging the two profiles if they represent the same person — then a single profile owns all the identifiers and the import can succeed.
Once the identifiers are consistent, resend the import or edit. The operation will go through.

​
How to avoid it

  • Send the minimum set of identifiers you actually need. Extra identifiers raise the chance of pulling in one that belongs to another profile.
  • Keep the identifier you treat as the primary key (for example, CRM ID or website ID) stable in your source system, and use it consistently across imports.
  • Reconcile duplicate or stale profiles regularly so old identifiers do not linger and trigger conflicts on future imports.