I have an API injecting records into mautic. In several instances the record already exists in mautic but has a different email address. I am able to identify them as being duplicates via matching a custom field, in the case csa_no
Is it possible to create a campaign, or some other method, to automatically check for duplicates based on the custom field and then merge the 2 records?
As you already use the API, maybe you could query for matching contacts and merge the data on your side? In my experience Mautic is very limited when you try to do such things within an campaign.
Not being a coder, could I ask you to break down your code with a few explanations so I can better understand it and adapt it to my needs?
I use n8n to manage the API side of things and they have a function node I could use to get the job done. The hard part for me is the actual function…
Unfortunately I do not have any practical experience with n8n. In lingers in my bucket list for some time now, but as a programmer the more natural way is to code it directly.
Maybe you can try to merge the contacts on the CLI level, but I also did not use that yet.
Look for the command mautic:contacts:deduplicate and for reference here:
I think you may need a helping hand from some IT guy.
Coming in way late here, but wanted to share how I have done this successfully within n8n/mautic environment.
Inside n8n, I’ll ping the mautic api with a get request with contact id. This returns the contact by ID and all custom field data. If you don’t have a contact ID, make http request with mautic’s Search feature, using your desired custom field (csa_no) and value, to find the right existing contact(s).
From here, you can use the IF node in n8n to check if more than 1 contact exists with the given csa_no value. Then, you can make a put or patch request (depending on your use case) to update your correct contact. Other contact(s) can be removed.
Now the actual data sync will require some planning… A simplified approach might check each matching contact and use the data from the most recently updated contact. A more intuitive approach might require checking event history from each contact to decide which data should be kept, and which should be overwritten.
Hope this helps, although I imagine you solved this by now.