mailchimp - mailchimp api目前不允许更多注册

Question

使用Mailchimp API，我取消了列表用户的订阅。然后，我立即发送新请求，以使用Mailchimp API重新订阅同一用户。
我收到400错误的错误请求，并显示以下消息:

(...) as signed up to a lot of lists very recently; we're not allowingmore signups for now

我要等待多久才能进行新查询？
如何解决这个问题？

Answer 1

tl; dr
5分钟后，1天之后，2天之后以及7天之后重试。

(太)长版本
我们也遇到了这个问题，有大量的订阅，对此响应(无用):

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}"
}

linked error glossary也没有太大帮助:

400

BadRequest

Your request could not be processed.

This is a generic error.

让实验开始!
我们从直接调用MailChimp API切换到将所有订阅请求保存在数据库中(我承认，我们应该一直这样做)。该表如下所示:

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`)
);

然后，我们设置一个cron作业，以定期检查需要与以下查询同步的订阅:

SELECT `id`
FROM `subscribes`
WHERE `synced` IS NULL
AND `failed` IS NULL
AND (`retry` IS NULL OR `retry` < UTC_TIMESTAMP())

对于每个订阅， attempts都会增加。如果订阅有效，则使用当前时间戳更新 synced。否则， retry会根据 attempts的值设置为将来的日期，如果我们用尽了尝试，则 failed会设置为当前时间戳。
最初的一组延迟(最近一次尝试之后)如下:

5分钟

1小时

6小时

1天

2天

7天

要使这些预订完全重试，需要10天，7小时和5分钟。
目前，我们距离测试只有3周的时间，但是它产生了有用的结果，所以我想现在就在这里发布:

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%

较短的延迟可以帮助解决网络错误或MailChimp api的临时问题(这是很不常见的)，而较长的延迟(1天或更长时间)可以解决“目前不允许更多注册”问题。在MailChimp中，仍然有少数“成功”并标记为“已清除”的订阅，但这是可以预期的，并且绝大多数订阅已成功完成。
我的(非正式)推荐

How long will I wait for a new query ? How to fix this ?

我建议您运行自己的测试，看看有什么用!但是，如果您只想从其他方面获得帮助，那就可以了:
我建议在5分钟后，1天之后，2天之后以及7天之后重试。之后可能再次获得该.51％的订阅，但是我没有数据来验证它是否可以正常工作。
延迟5分钟导致订阅人数增加了0.16％。这有助于及时为某人订阅即将发送的电子邮件，从而避免了“我已注册但未收到新闻通讯”的投诉。这对我们来说并没有吸引很多订阅者，但是对于MailChimp api(或网络中的某个地方)发生短时间中断的情况，这真是太好了。
1小时和6小时的延迟对我们没有任何帮助，因此可能没有必要。但是结果可能会有所不同。再次，这对于短时间的中断来说会更多，因此您真的不知道最好的延迟，直到它发生。确定最适合您的需求，然后再去做。
1天的延迟使订阅的人数增加了4.7％以上(〜11％的重试成功了)。如果他们尝试订阅当天发生网络或MailChimp api问题，则第二天将使该人订阅。我会推荐。
延迟2天导致订阅人数增加了17.72％以上(〜80％的重试成功)。绝对推荐。
延迟7天导致了另外3.34％的订阅(〜80％的重试成功)。推荐的。
注意:我们尚未自行测试1、2和7天的延迟。也许它们本身并没有那么有用，但是堆叠在一起是它们成功的原因(例如，延迟2天失败，但是延迟3天7小时5分钟有效)。