Using the Mailchimp API, I unsubscribed a user of a list. Then I immediately send a new request to resubscribe the same user using the Mailchimp API.
I got 400 error bad request with this message:
(...) as signed up to a lot of lists very recently; we're not allowing more signups for now
How long will I wait for a new query?
How to fix this?
Retry after 5 minutes, 1 day after that, 2 days after that, and 7 days after that.
We ran into this issue as well with a large number of subscribes, with this (unhelpful) response:
HTTP 400 Bad Request
Server: openresty
Content-Type: application/problem+json; charset=utf-8
Content-Length: 301
X-Request-Id: {requestId}
Link: <https://us14.api.mailchimp.com/schema/3.0/ProblemDetailDocument.json>; rel="describedBy"
Date: {date}
Connection: close
Set-Cookie: _AVESTA_ENVIRONMENT=prod; path=/
{
"type": "http://developer.mailchimp.com/documentation/mailchimp/guides/error-glossary/",
"title": "Invalid Resource",
"status": 400,
"detail": "{email} has signed up to a lot of lists very recently; we're not allowing more signups for now",
"instance": "{instance}"
}
The linked error glossary isn't much help either:
400
BadRequest
Your request could not be processed.
This is a generic error.
We switched from directly calling the MailChimp API to saving all subscribe requests in our database (which, I admit, we should have been doing all along). This table looks something like:
CREATE TABLE `subscribes` (
`id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`email` varchar(254) NOT NULL,
`json` varchar(500) NOT NULL,
`subscribed` datetime NOT NULL,
`ip` int(10) unsigned NOT NULL,
`retry` datetime DEFAULT NULL,
`attempts` int(11) DEFAULT 0,
`synced` datetime DEFAULT NULL,
`failed` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `unsynced` (`synced`,`failed`,`retry`,`id`)
);
We then set up a cron job to periodically check for subscribes that need to be synced with a query like this:
SELECT `id`
FROM `subscribes`
WHERE `synced` IS NULL
AND `failed` IS NULL
AND (`retry` IS NULL OR `retry` < UTC_TIMESTAMP())
For each subscribe, attempts is incremented. If the subscribe works, synced is updated with the current timestamp. Otherwise, retry is set to a date in the future based on the value of attempts, or failed is set to the current timestamp if we have run out of attempts.
Out initial set of delays (after the most recent attempt) are as follows:
For a subscribe to be fully retried with these delays, it would take 10 days, 7 hours, and 5 minutes.
We're currently only about 3 weeks into the test, but it's produced useful results, so I figured I'd post here now:
after last | after first | % subscribed
-----------|-------------|-------------
- | - | 73.45%
5 minutes | 5m | 73.61%
1 hour | 1h 5m | 73.61%
6 hours | 7h 5m | 73.61%
1 day | 1d 7h 5m | 78.43%
2 days | 3d 7h 5m | 96.15%
7 days | 10d 7h 5m | 99.49%
The shorter delays can help work around network errors or temporary issues with MailChimp api (which are fairly uncommon), while the longer delays (1 day and longer) work around the "not allowing more signups for now" issue. There were still a small number of subscribes that "succeeded" and marked as "cleaned" in MailChimp, but that's to be expected and the vast majority were subscribed successfully.
How long will I wait for a new query ? How to fix this ?
I'd suggest running your own tests to see what works for you! But, if you just want to get something out the door that has worked for others:
I'd suggest retrying after 5 minutes, 1 day after that, 2 days after that, and 7 days after that. Possibly again after that to catch that additional .51% of subscribes, but I don't have data to verify that it would work.
5 minute delay resulted in .16% more people subscribed. This helps to subscribe someone in time for an email that is going to be sent out soon, which avoids "I signed up but didn't receive the newsletter" complaints. This didn't catch many subscribers for us, but for those times that the MailChimp api (or somewhere along the network) has a short outage, this is nice to have.
1 and 6 hour delays didn't do anything for us, so it's probably not necessary. But results may vary. Again, this would be more for short outages, so you don't really know the best delay until it happens. Decide what fits your needs best and go with that.
1 day delay got more than 4.7% more people subscribed (~11% of retries succeeded). This will get the person subscribed the next day if there was a network or MailChimp api issue on the day they tried to subscribe. I would recommend.
2 day delay resulted in more than 17.72% more people subscribed (~80% of retries succeeded). Definitely recommended.
7 day delay resulted in another 3.34% subscribed (~80% of retries succeeded). Recommended.
Note: We have yet to test 1, 2, and 7 day delays on their own. It could be that on their own, they aren't that useful, but stacked together is why they succeed (eg, 2 day delay fails, but a delay of 3 days 7 hours and 5 minutes works).
This error message is related to a throttle that Mailchimp have in place to prevent spammers from inundating audiences with fake signups. When Mailchimp system recognizes that an email address is being added to a large number of audiences within a small window of time (or a variant of the address like with these alias addresses), we will throttle signup activity for that email address for up to 48 hours.
This is response from support. you would have to wait for 48 hours to excldue that email, or you can use different email, or you can dd it from Mailchimp Add audience
This is weird kind of rate limiting that Mailchimp had put up. It happens when you generally trigger email with xyz@example.com, xyz+1@example.com, xyz+2@example.com . They do rate limiting and requests throttle.
You generally will have to wait for certain window size (in this case 48 hours).
