La fonction de suggestion automatique permet d'affiner rapidement votre recherche en suggérant des correspondances possibles au fur et à mesure de la frappe.
Hi everyone, I am facing a weird issue here. I make a call to /crm/v3/objects/contactsand create a contact, it succeeds and creates a new contact for me.
Then I make a call to check their subscription status at /communication-preferences/v3/status/email/{emailAddress} with the email address used in the precedent call, and it returns a success too.
But the problem is when I re-call the second endpoint with a fake email address that doesn't exist, it still returns a 200 and the old JSON body, I am very certain that shouldn't happen.
I can call the second endpoint will multiple emails and it returns the same subscribed status.
Hey, @MR8👋 Thanks for posting this over here. I am adding information here for anyone else that bumps into this behaviour. The answer is this is working as designed. This behaviour is confusing, in my opinion, and your feedback has been shared with the team.
Here are some additional details: For this endpoint, even when a fake or invalid email is used, HubSpot will calculate the effective statuses. The contact won’t have any statuses, so everything will be NOT_OPTED (an internal designation) and the endpoint will use that. For GDPR enforced portals, they’ll be NOT_SUBSCRIBED and for non-GDPR portals, they’ll be SUBSCRIBED. (This is why you are getting a 200 response — Jaycee)
With the invalid email, we get a SUBSCRIBED response. And that is technically correct, but in-practice unexpected.
Hey, @MR8👋 Thanks for posting this over here. I am adding information here for anyone else that bumps into this behaviour. The answer is this is working as designed. This behaviour is confusing, in my opinion, and your feedback has been shared with the team.
Here are some additional details: For this endpoint, even when a fake or invalid email is used, HubSpot will calculate the effective statuses. The contact won’t have any statuses, so everything will be NOT_OPTED (an internal designation) and the endpoint will use that. For GDPR enforced portals, they’ll be NOT_SUBSCRIBED and for non-GDPR portals, they’ll be SUBSCRIBED. (This is why you are getting a 200 response — Jaycee)
With the invalid email, we get a SUBSCRIBED response. And that is technically correct, but in-practice unexpected.