现在不允许在 mailchimp 中进行更多注册 api

Question

使用 Mailchimp API，我退订了一个列表的用户。然后我立即发送一个新请求，使用 Mailchimp API.

重新订阅同一用户

我收到 400 错误请求错误消息：

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

我需要等待多长时间才能收到新查询？

如何解决这个问题？

Answer 1

tl;博士

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 切换到将所有订阅请求保存在我们的数据库中（我承认，我们应该一直这样做）。这个 table 看起来像：

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 周的测试，但它产生了有用的结果，所以我想我现在 post 在这里：

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 分钟有效）。

Answer 2

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. 这是来自支持的回应。您必须等待 48 小时才能排除该电子邮件，或者您可以使用不同的电子邮件，或者您可以从 Mailchimp 添加受众

Answer 3

这是 Mailchimp 提出的一种奇怪的速率限制。当您通常使用 xyz@example.com, xyz+1@example.com, xyz+2@example.com 触发电子邮件时，就会发生这种情况。他们进行速率限制并请求节流。

您通常需要等待特定的 window 尺寸（在本例中为 48 小时）。

现在不允许在 mailchimp 中进行更多注册 api

not allowing more signups for now in mailchimp api

mailchimp

tl;博士

（太）长版

400

BadRequest

实验开始！

我的（非官方）推荐