I'm working on an integration with SendGrid where users of my website can add themselves to SendGrid contact lists for the sake of email marketing. These users can of course subsequently unsubscribe via SendGrid unsubscribe groups.
I have what I assume is a common scenario where a user updates their email address. I had assumed, since the SendGrid contact entity in its RESTful API is keyed on a GUID-like string ID, that changing the email would be a simple patch operation. But it seems far from it.
Firstly, according this this doc the only contact mutating operation is a PUT, and this will update one or more contacts that are identified by at least "one of email, phone_number_id, external_id, or anonymous_id. In other words, I can't change the email based on the actual ID. It would appear all these identifier types are immutable.
I've read elsewhere that the only option in my scenario is to create a new contact and delete the old one. OK, so first I need the contact ID. Apparently the only way to obtain this (if you don't already have it) is to use the search by email endpoint then parse the maddeningly structured response (where email values are used as JSON property names!). Having read the contact like this I then can create a new contact with the same contact list references as the old one. I can then delete the old contact.
This is a huge faff but achievable. However, what if the original contact had unsubscribed via the unsubscribe group of one of these lists? I can't be in a situation where a website user by changing their email suddenly finds themselves resubscribed to marketing they don't want, which I'm fairly sure would go against GDPR regulations. Am I forced to additionally determine which unsubscribe groups the original contact belonged to and replicate their unsubscribes?
This whole process seems so badly designed for what must be an extremely common scenario so I'm hoping someone out there can tell me what I'm missing.
I've read elsewhere that the only option in my scenario is to create a new contact and delete the old one.
From when I last checked a year or so ago, this still holds true. This is how I've implemented it in my application.
OK, so first I need the contact ID. Apparently the only way to obtain this (if you don't already have it) is to use the search by email endpoint
This used to be true, and is still a valid way to get the contact details associated with an email. However, sometime in the summer of 2024 (based from Internet Archive results) SendGrid added a new "Get Contacts by Identifiers" endpoint. The response format seems exactly the same as the search endpoint.
Additionally, take into account that contact creation is an asynchronous process that may take several minutes to complete, so the contact ID is not immediately available after creation. Other operations such as adding a contact to a list may also have a delay of seconds or minutes to be visible to subsequent "GET"-type requests.
Am I forced to additionally determine which unsubscribe groups the original contact belonged to and replicate their unsubscribes?
I'm afraid so, yes. I would also check if a deleted contact's email address is also removed from a Global or Group unsubscribe list. It may just as well remain, which is probably not an immediate problem for you, but it might cause an unexpected situation if the user re-subscribes on the new email and then reverts to the old email and has their emails blocked (admittedly unlikely).
I mostly don't use Unsubscribe Groups. I use list membership to denote whether a contact is subscribed or not. If they unsubscribe, I remove them from the list (I don't use the SendGrid-managed preference center because it doesn't support multilingual/regional scenarios). This may also be an option for you, but I'm running into other challenges here due to the intervals in which segments update based on list membership. Unsubscribe Groups are probably more reliable.
This whole process seems so badly designed for what must be an extremely common scenario so I'm hoping someone out there can tell me what I'm missing.
I agree that this developer experience is horrific. I don't think you're missing anything though.