Blog Screenshot 1.png

Marketo Engage's Sync Lead REST API with Additional Dedupe Fields

Marketo Employee
Marketo Employee

Occasionally, customers will have a use case where they're required to consider intentional duplicate person records in Marketo Engage, adding a field to the "dedupe fields" in addition to email address. Typically that'll take the form of a member_number, accountID, or something similar.


In order to accomplish this, you'd need to reach out to support or consulting and explain your use case, and they can enable this as you wish on the back end.


I won't bore you again about the unintended consequences of duplicates in Marketo like I did in 2015. Rather, I'll discuss how you can expect the API to act with regard to pushing those records into Marketo because there is some behavior you might not expect.


In this blog post, I'll specifically be addressing the case where you're using the Sync Lead REST API call and attempting to push Person records who have the same Email address but have a different "extra" duplicate key. In this case, I'll use "Account ID"


It's also important to note that in this blog post, I'll be dealing with a single Person Partition. The case where you have multiple Person partitions is another topic for another day.


When you send data into Sync Lead, the payload looks like this in a typical use case (when you are not overriding the dedupe field). Ignore the partitionName for now, it has no bearing on this example. So with the Dedupe field overridden to be email + account Id, you might expect you'd use the same payload, including the "lookupField".


Blog Screenshot 1.png


Importantly you'll notice

  • The payload contains values for *both* the email address and the account ID
  • The payload contains the "lookupField" which is set to "email"

This call succeeds, and the Person record is created. All is well.


The problem arises when we send in a second call with a different accountID, expecting that since we changed the dedupe rule to be "email address" AND "account ID".. that it will create a duplicate. We'd then have two person records with the same email, but different account IDs... but that isn't what happens.


Blog Screenshot 2.png


What!? It updates the single existing Person record? Why?!


As it turns out, the API sees that you are still passing in the lookupField. Recall that this field is optional. since you've sent it in, it's honoring that field.. and just updating the existing record.


In order to have the API honor the overridden dedupe criteria.. you need to OMIT the lookupField, and of course ALWAYS (always, always) include both the Account ID and the email address, and it will create the duplicate as you expect.


Blog Screenshot 4.png


Note that gets worse if you already HAVE duplicates in place (remember, Marketo, a "duplicate" is two person records having the same email).. and you subsequently INCLUDE the "lookupField" in your payload. At that point, you'll have a problem. Strictly speaking, it's an error but in reality, it's just the API letting you know that you can't upsert a Person when you aren't uniquely identifying a Person.


Blog Screenshot 5.png


Yikes. This, you do not want.


Even worse, if you make your REST API call, but OMIT either the email address or the account ID, the API will create a duplicate EVERY TIME.


In summary, if you have decided you need to override the dedupe rule, work with support to enable that, and ensure that you always include both the enauk address and the new dedupe field (like accountID here) and omit the lookupfield.


1 Comment