TL; DR
Try again in 5 minutes, 1 day after that, 2 days after this and 7 days after that.
(version is too long)
We ran into this problem and with a lot of subscribers with this (useless) answer:
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 glossary of errors doesn't help much:
400
Badrequest
Your request could not be processed.
This is a common mistake.
Let the experiment begin!
We moved from calling the MailChimp API directly to store all subscription requests in our database (which, I admit, we had to do everything together). This table looks something like this:
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`) );
Then we configure the cron job to periodically check subscribers who should be synchronized with this request:
SELECT `id` FROM `subscribes` WHERE `synced` IS NULL AND `failed` IS NULL AND (`retry` IS NULL OR `retry` < UTC_TIMESTAMP())
For each subscription, attempts increase. If the subscription works, synced updated with the current timestamp. Otherwise, retry set in the future depending on the value of attempts , or failed set to the current timestamp if we have finished trying.
The initial set of delays (after the last attempt) is as follows:
- 5 minutes
- 1 hour
- 6 hours
- 1 day
- 2 days
- 7 days
For the subscription to be completely repeated with these delays, it would take 10 days, 7 hours and 5 minutes.
Currently we are only testing for about 3 weeks, but this has yielded useful results, so I decided that I posted 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%
Shorter delays can help bypass network errors or temporary problems with MailChimp api (which is rather unusual), while longer delays (1 day or more) work around the problem of "not allowing more registration at the moment." There were still a small number of subscribers who “succeeded” and were marked as “cleared” in MailChimp, but this was expected, and the vast majority were signed successfully.
My (unofficial) recommendation
How long will I wait for a new request? How to fix it?
I would suggest running your own tests to see what works for you! But, if you just want to get something from a door that worked for others:
I suggest retrying after 5 minutes, 1 day after that, 2 days after that and 7 days after that. It is possible again after that to catch that additional .51% of subscribers, but I do not have the data to verify that it will work.
A 5-minute delay led to an increase of 0.16% in subscribers. This helps to timely subscribe to the letter that will be sent in the near future, which will help to avoid "I signed, but did not receive the newsletter." This did not attract many subscribers for us, but for those cases when the MailChimp api (or somewhere on the network) has a short break, it is nice to have it.
The 1 and 6 hour delays did nothing for us, so this is probably not necessary. But the results may vary. Again, this would be more for short outages, so you don’t know what kind of delay until this happens. Decide what best suits your needs and go with it.
The 1-day delay received more than 4.7% more subscribers (~ 11% of success attempts). This will force a person to sign up the next day, if the day they tried to sign up, there is a problem with the network or MailChimp api. I would recommend.
The 2-day delay resulted in 17.72% more subscribers (~ 80% success attempts). Definitely recommended.
A 7-day delay led to another 3.34% subscribing (~ 80% success attempts). Recommended.
Note: We still need to check the delays for 1, 2 and 7 days. Maybe this in itself, they are not so useful, but stacked together, so they succeed (for example, a 2-day delay does not work, but it works 3 days 7 hours and 5 minutes).