CODEWITHSUNDEEP
mailchimpmailchimp-api-v3.0
Arne Cordes
Arne Cordes

Reputation: 581

MailChimp API resubscribe confirmation mail not longer sending

When a contact with status unsubscribed tries to subscribe with the same mail address again, I send a PUT request with status pending in order to trigger the opt-in process.

Suddenly the confirmation mail stopped from being sent. The contact switched from unsubscribed to pending, but has no chance to confirm its subscription.

This is a shortened version of the code:

<?php
$member_response = $MailChimp->get("lists/$list_id/members/$subscriber_hash"); // <-- Returns an array where status is `unsubscribed`

if($member_response['status'] == 'unsubscribed' || $member_response['status'] == 'pending') {
  // User exists but is not active. Do a PUT request with new values to trigger re-opt-in
  $update_response = $MailChimp->put("lists/$list_id/members/$subscriber_hash", $member_data); // <-- Returns an array where status is `pending`
}
?>

Shouldn´t the confirmation mail being sent when setting an existing subscriber to pending again?
Do I overlook something?

Upvotes: 3

Views: 1942

Answers (2)

user22957214
user22957214

Reputation: 1

If you send PATCH request, than confirmation email is sent to email address, while the PUT one doesn't.

For my needs, as I have to re-subscribe users "behind the scenes", I have to use PUT.

Upvotes: 0

William Turrell
William Turrell

Reputation: 3326

To follow up on my previous comment, here's a summary of the answers I got from MailChimp earlier this month.

  • This (unannounced) change, unrelated to v3 API, was made in September 2016.
  • When a user unsubscribes, they can't be resubscribed by you. We already knew that, but the trick with changing 'status' back to 'pending' which used to trigger a new email every time you made an API request no longer works - emails are now throttled. Originally MailChimp told me the exact rate was on a list by list basis, but when I followed up they later said it was 48 hours after the first attempt (and any subsequent attempts during that period would reset the timer.)
  • MailChimp confirmed there is no logging of the confirmation request emails, or a way in the API / admin UI to determine if they were sent (other than knowing that when a subscriber is set to pending the first time the email will automatically be sent.)
  • It seems to me it is now possible to re-add users manually via admin.mailchimp.com, regardless of their previous status – I'm not sure this worked before. Curiously, this changes someone's status back to subscribed without requiring any confirmation by them. (if I can do that via the UI, why can't I do it via the API, etc.)

  • I asked if addresses identical except for a the use of a plus sign, e.g. [email protected] and [email protected] would be counted as two separate addresses given they produce different subscriber hashes, as used in the API endpoints. (During testing, I frequently use my one address and change the end of it to denote the date, use a counter etc.) They actually told me they're not counted as uniques: the algorithm that controls signup limits resolves them to the same address, which I wasn't expecting.

  • Finally, their API helpdesk (who send prompt and courteous responses - you don't need to have an account to write to them either) have the ability to manually check the status of an individual address for you on an ad-hoc basis.

Personal Opinion:

My impression is MailChimp would like to push people towards using their 3rd-party hosted / embeddable forms for handling signups, rather than using the API.

Reading between the lines, I wonder if they have been on the receiving end of a large number of spam complaints / blacklisting, given the free-tier and the number of customers they now have.

Although the v3 API is a big improvement in architecture over the previous version, updating code (including, in my case, a WordPress plugin) to use it was a fair bit of work, and there have been multiple unannounced and/or short notice disruptive changes with MailChimp products in recent year; the discontinuation of Mandrill, outdated security certificates on API servers, etc.

Actually, I'm struggling to think of another 3rd-party service which has repeatedly required this much development time just to keep a small group of API features operational (subscription, unsubscription and interest groups, in the case of my clients). This is less a comment on the quality of the product and more the workload it generates for developers.

It's quite possible this will continue to be the case, so I'd encourage people to think carefully before selecting a bulk email service if you don't want to have to deal with situations where, for example, you can't detect if and when someone was sent an opt-in confirmation.

Upvotes: 3

Related Questions