19

I'd like to know if the Mailchimp API v3.0 allows for the EMAIL address to be changed for a subscriber.

This is what I have:

$email = strtolower(trim($oldEmail));
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    return false;
}
$emailHash = md5($email);

$result = $this->patch('/lists/'.$listid.'/members/'.$emailHash, 
    array(
        'email_address' => $oldEmail,
        'merge_fields' => array("EMAIL" => $newEmail),
        'status' => "subscribed",
    ));

And it doesn't work. Mailchimp returns the usual GET MEMBER response, and shows that nothing has been changed.

Any idea?

Thank you, Riccardo

Guerriky
  • 529
  • 1
  • 5
  • 15

5 Answers5

13

I know that this is a bit late but right now the PUT method (.../3.0/lists/{listId}/members/{md5}) allows to change the email address.

I'm sending the new email in the body and MERGE0 (EMAIL) tag but using the md5 from the previous email. It is changing the email correctly.

Marcs
  • 3,768
  • 5
  • 33
  • 42
juanjose_hg
  • 166
  • 1
  • 5
  • 1
    Hi juanjose_hg, you're not late at all, in fact the official changelog lists that as recent as November of this year (http://developer.mailchimp.com/documentation/mailchimp/guides/changelog/). Since your answer refers to the same version of the api that I asked for, I'm going to accept yours instead. Sorry, @TooMuchPete, hope you don't mind. – Guerriky Dec 05 '16 at 14:56
10

According to the docs, it does. It does not work on our side either, so we'll contact Mailchimp to know the reason why it's in the doc.

EDIT: It is indeed not possible, the documentation was outdated. Here is what mailchimp had to say about this:

Hi Philipp, ​ Thanks for reaching out to MailChimp support with those API concerns, and for allowing us to assist. ​ With MailChimp version 3.0, users cannot update a subscriber email address. While this may have been available with past versions of our API, it is no longer supported. To update a subscriber email address, the best move will be to manually update from within MailChimp. Each email address is considered to be a unique identifier for list members. ​ I can certainly understand how the documentation can be a bit misleading, and you do have the ability to update subscriber fields in the list, however email address is not one of them. This is why you have not seen that information updated in MailChimp. I will be reviewing the documentation on this end, and making suggestions to have that article edited if indeed we are suggesting that email addresses can be updated using API. Thanks for this feedback, and for hanging in with us. ​ We appreciate your time, energy and patience as we reviewed things on our end. Thank you again for choosing MailChimp, and keep us posted with any other questions that you may have moving forward. ​

born4new
  • 1,677
  • 12
  • 12
9

According to MailChimps changelog changing the email of a user is possible since 3rd of November 2016 with patch and put.

11/03/2016

Add the ability to update an existing list member’s email_address through a PATCH or PUT call to /lists/{list_id}/members/{subscriber_hash}

You do not need to use merge_field to change the email. You can simply do it like this:

$emailHash = md5($oldEmail);

$result = $this->patch('/lists/'.$listid.'/members/'.$emailHash, 
    array(
        'email_address' => $newEmail,
        'status' => "subscribed",
    ));
Adam
  • 25,960
  • 22
  • 158
  • 247
  • works for me. To note here: the "subscriber hash" (ID) doesn´t change. Means you have to *know* the ID of the subscriber of have to work with the email adress insteat of the hash?! – cljk Jul 07 '23 at 08:42
5

No, MailChimp doesn't really allow email addresses to be changed. You can do it in the web app, but almost all stats and activity information don't carry over. API v3.0 doesn't support changing email addresses at all for that reason. What you want to do is unsubscribe or delete the old address and then re-create the new one.

TooMuchPete
  • 4,583
  • 2
  • 17
  • 21
  • Hi Pete. Guess I'll lose all the subscriber's stats anyway. Thanks for the clarification :) – Guerriky Aug 27 '15 at 08:21
  • Really?! That's seriously bad system design. – TheStoryCoder Mar 21 '16 at 12:06
  • I'm not sure it's a "bad system design" so much as it is a different one than you'd prefer. The list is just a collection if email inboxes. A person can change which email address they use, but email addresses themselves can't change. Think of it like a street address: a person can move from one to another, but you can't just change the address of a house. – TooMuchPete Mar 21 '16 at 16:08
  • @TooMuchPete how come [request body of PATCH and PUT](http://developer.mailchimp.com/documentation/mailchimp/reference/lists/members/#edit-put_lists_list_id_members_subscriber_hash) method `PATCH /lists/{list_id}/members/{subscriber_hash}` have both parameter `email_address *` required. You already pust md5(lower_case_email_address) in request URl. To say in other words, what purpose does email_address have in this API methods. I tried setting another email, but it doesn't change as Guerriky tested already. Aslo are there limits e.g. max allowed requests per minute from one IP? – broadband Mar 25 '16 at 11:40
  • `email_address` is permitted for PUT because it is a create-or-update command. You'll need the email address in case it doesn't exist. For PATCH, `email_address` is not required (or used). – TooMuchPete Mar 25 '16 at 22:06
  • 2
    @TooMuchPete Sounds like you have been studying higher education too much - nice theory but no use in real life :) Loosing subscriber stats is one thing, but much worse is that it becomes really tedius to make integrations. I have a CMS with all customers and need to sync with MailChimp. It's like using postal address as primary key for your customers and whenever they change their address you need to change all foreign key records as well - it's madness and a data normalization no-no! – TheStoryCoder May 05 '16 at 20:28
  • 1
    @TheStoryCoder Using an address as a PK for a person would be silly, that's true. Using it as a PK for a house is a different thing and much more reasonable. That's exactly the distinction here, too. MailChimp is not, at present really built to send to people so much as it is mailboxes. Those things are often 1:1 but not always, as you've seen. It's a trade-off that could change over time, but that's how it is now. – TooMuchPete May 06 '16 at 17:58
  • 2
    I'm doing an integration also and I agree with @TheStoryCoder. This is super annoying. Integrating with MailChimp is turning out to be much harder than I expected. – nmit026 May 09 '16 at 04:41
  • I can certainly be annoying for particular use cases, no doubt. That's the case with all trade-offs, though. – TooMuchPete May 09 '16 at 14:58
  • 2
    @TooMuchPete I don't know how happy SO is for our debate here but I dare to make one more point. You're talking all theory. I don't see what we are practically gaining by this design (other than maybe making programming MC easier - but that's a wrong attitude to have, computers are to simplify things for us). So I don't understand how you can call it a trade-off. – TheStoryCoder May 15 '16 at 19:04
  • 1. This is a relatively rare complaint, many MC users never run into this problem. 2. There's no higher-level entity within MailChimp to represent a "person", so the primary difference is whether stats should be kept between email addresses. 3. The stats associated with an email address can be used to catch undesirable behavior (such as spamming), so allowing those to be arbitrarily changed without a higher-level abstraction for "person" can lead to undesirable behavior slipping through the cracks. – TooMuchPete May 16 '16 at 18:44
  • @TheStoryCoder Just stating for the record, I couldn't agree with you more. – Justin Kimbrell Sep 29 '16 at 19:26
0

of course you can update email address, use

PATCH /lists/{list_id}/members/{hashed_old_email_address}

and set the new email address in the payload https://mailchimp.com/developer/marketing/api/list-members/update-list-member/

helvete
  • 2,455
  • 13
  • 33
  • 37
Sir_Mc_Tod
  • 21
  • 1