4

I'm working with the Mailchimp API v3.0 to mutate list members.

Archiving members works without issues using the following endpoint:

DELETE /lists/{list_id}/members/{subscriber_hash}

The web-interface allows me to "unarchive" a member, reverting it back to it's previous state.

web-interface unarchive

I haven't found this functionality in the API documentation yet.

I was able to unarchive the member by using the endpoint:

PATCH /lists/{list_id}/members/{subscriber_hash}

with body:

{"status": "subscribed"}

Although this does unarchive the member, this doesn't restore the status of the member. It simply sets the status to "subscribed" as provided in the body.

I'd like restore a member to its status before archiving. If a member was subscribed before archiving, then I would like it to be subscribed after unarchiving. Similarly if a member was unsubscribed before archiving, then they should be unsubscribed after unarchiving. Similar to what the web-interface does.

When retrieving the data of an archived member the return data does not include the status before archiving.

How can I unarchive a member using the Mailchimp API? Am I overlooking something, or is this functionality missing from the API?

3limin4t0r
  • 19,353
  • 2
  • 31
  • 52
  • I have the same problem... Any updates? – Bruno Croys Felthes Sep 11 '20 at 15:22
  • 1
    @BrunoCroysFelthes yes, I've contacted Mailchimp support yesterday and I have a band aid solution, but no real fix yet. I will post it as an answer, but will not mark it as accepted answer, since that should be reserved for a real fix. – 3limin4t0r Sep 11 '20 at 15:39

1 Answers1

3

I've had contact with the Mailchimp support team and currently have a band aid solution.

Let me first add some additional info that is not provided in the documentation (this comes from my chat session with the support team):

Overall from what I'm seeing, there does not appear to be a specific method to unarchive contacts without altering their original status. However while contacts who unsubscribed on their own will not be affected by the status change, other contacts who were manually unsubscribed (by you or someone else through the account/api) they will have that updated since that is considered a type of admin action.

With the above info my current solution is to update a list member to status "subscribed". If this fails with an 400 error I assume that the member unsubscribed at their own and send another request, this time using status "unsubscribed".

So:

PATCH /lists/{list_id}/members/{subscriber_hash}
{"status": "subscribed"}

If above results in status 400 then:

PATCH /lists/{list_id}/members/{subscriber_hash}
{"status": "unsubscribed"}

This solution still leaves a lot to be desired. This effectively means you cannot unarchive list members that you've given the status "unarchived" yourself. You also have to make 2 requests for list members that unsubscribed.

I've send a feedback email suggesting to add the resource:

POST /lists/{list_id}/members/{subscriber_hash}/actions/unarchive

Which is consistent with their permanent delete list member resource.

3limin4t0r
  • 19,353
  • 2
  • 31
  • 52
  • Hello, thanks for sharing this info with us. I am not sure I understand why you send the 2nd request with `unsubscribed` status if a member is already unsubscribed? As I understood, if the first request responds with 400, it means that a member was unsubscribed at their own and he already has `unsubscribed` as a status? Why this 2nd request is needed? 400 means that you are not allowed to update a member with `subscribed` because he already stores `unsubscribed` as a value? It looks like the 2nd request is redundant in this case. – Vladyslav Turak Dec 04 '20 at 11:10
  • 2
    @VladyslavTurak Since the question is about unarchiving the current status of the member is "archived", not "unsubscribed". Since the status cannot be changed to "subscribed" (because the member unsubscribed at their own) we can then remove the "archived" status by setting the status to "unsubscribed". – 3limin4t0r Dec 04 '20 at 11:53