更改 SendGrid 联系人的电子邮件真的像我想象的那么复杂吗？

Question

我正在与 SendGrid 进行集成，我的网站的用户可以将自己添加到 SendGrid 联系人列表中，以便进行电子邮件营销。这些用户当然可以随后通过 SendGrid 取消订阅组取消订阅。

我认为这是一个常见的场景，即用户更新他们的电子邮件地址。我曾假设，由于其 RESTful API 中的 SendGrid 联系人实体以类似 GUID 的字符串 ID 为键，因此更改电子邮件将是一个简单的修补操作。但好像还差得很远。

首先，根据此此文档，唯一的联系人变异操作是 PUT，这将更新至少由“

email

、

phone_number_id

、

external_id

或

anonymous_id”之一标识的一个或多个联系人

. 换句话说，我无法根据实际 ID 更改电子邮件，它会出现所有这些标识符类型。是不可变的。

我在其他地方读到，在我的场景中唯一的选择是创建一个新联系人并删除旧联系人。好的，首先我需要联系 ID。显然，获得此信息的唯一方法（如果您还没有）是使用 通过电子邮件端点搜索，然后解析令人发狂的结构化响应（其中电子邮件值用作 JSON 属性名称！）。读完这样的联系人后，我可以使用与旧联系人相同的联系人列表引用创建一个新联系人。然后我可以删除旧的联系人。

这是一个巨大的失败，但可以实现。但是，如果原始联系人已通过这些列表之一的取消订阅组取消订阅怎么办？我不能遇到这样的情况：网站用户通过更改电子邮件突然发现自己重新订阅了他们不想要的营销内容，我相当确定这会违反 GDPR 法规。我是否被迫另外确定原始联系人属于哪些取消订阅组并复制他们的取消订阅？

对于一个极其常见的场景来说，整个过程似乎设计得很糟糕，所以我希望有人能告诉我我错过了什么。

Answer 1

我在其他地方读到，在我的场景中唯一的选择是创建新联系人并删除旧联系人。

从我上次检查大约一年前开始，这仍然成立。这就是我在我的应用程序中实现它的方式。

好的，首先我需要联系 ID。显然，获得此信息的唯一方法（如果您还没有）是使用通过电子邮件端点进行搜索

这也是事实。此外，请考虑到联系人创建是一个异步过程，可能需要几分钟才能完成，因此联系人 ID 在创建后不会立即可用。其他操作（例如将联系人添加到列表中）也可能会有几秒或几分钟的延迟，以便后续的“GET”类型请求可见。

我是否被迫额外确定原始联系人属于哪些取消订阅组并复制他们的取消订阅？

恐怕是的，是的。我还会检查已删除联系人的电子邮件地址是否也从全局或组取消订阅列表中删除。它可能会保留下来，这对您来说可能不是一个直接的问题，但如果用户重新订阅新电子邮件，然后恢复到旧电子邮件并使其电子邮件被阻止，则可能会导致意外情况（诚然，不太可能） ).

我基本上不使用取消订阅群组。我使用列表成员资格来表示联系人是否已订阅。如果他们取消订阅，我会将他们从列表中删除。这也可能是您的一个选择，但由于分段根据列表成员身份更新的时间间隔，我在这里遇到了其他挑战。退订群组可能更可靠。

对于一个极其常见的场景来说，整个过程似乎设计得很糟糕，所以我希望有人能告诉我我错过了什么。

我同意这种开发者体验是可怕的。有这种感觉的并不孤单。我不认为你错过了什么。