Subscriptions api calls failing silently


#1

Hello we are sending api calls when someone opts into one thing… to opt them out from the other categories.
e.g.
Opt into thing 1(001). Opt them out of thing 2(002) and 3 (003)
Example below

I get a successful response… but sometimes the preference is not update … even though the timeline shows the contact was opted out. Is anyone else having this issue? Can anyone advise how to work around or resolve?

NOTE I can typically try the exact same api call and it will work subsequent.

PUT https://api.hubapi.com/email/public/v1/subscriptions/test@test.com?hapikey=REMOVED HTTP/1.1

{
“subscriptionStatuses”: [
{
“id”: 002, “subscribed”: false
},
{
“id”: 003, “subscribed”: false
}
]
}


#2

HI @daperlman,

How are you checking that the contacts are opted out? Does it appear that the contacts are opted out on the timeline, but not when you check via the API? Can you send me an example contact where you saw this?


#3

Hi Derek,
Thanks for reply.
Can I paste a link to the contact from my hubspot instance? Can you see that?


#4

Hi Derek
Let me know if you can see this
https://app.hubspot.com/lists/2821157/list/308/
these folks all show update to prefs in the timeline… but the preference itself is not set. I can also provide the examples where the SAME call was used - but the prefs were updated


#5

Hi @daperlman,

Thank you for you patience here. Based on the property history for the email opt out property, the request to opt these contacts out of certain email types is coming in immediately after the contact is created. I believe there’s a race condition between the API calls you’re making to opt these contacts out and the internal processes that create contacts (since newly created contacts are opted into everything by default). Is there a way for you to slightly delay your subscription updates for new contacts?


#6

Hi Derek
if they were waiting for the response from the add / signup call… we still need to wait (even though it would be a synchronous process i.e. post opt in and wait for response then post opt out(s).)
I will ask the programmers for that website about that. If they can ‘delay’ the call - how long is needed?
I want to mention - that this only happens to some records … others are processed correctly.

The default behavior causes an issue here (i.e. opt in to all when adding a new record) cause this form they can choose category(s). Is there a better way to handle?

thanks!
keith


#7

One other case I want to mention here. Originally I was fixing these records using an api I wrote to bulk process them. i.e. load 1000 records (where opt out was not set) to this api… which sends them through the /subscriptions api. When I do this … most are resolved - but there are exceptions. The theory about the opt-in vs out timing would not explain this. I can probably recreate this by loading a bunch of dummy records.


#8

Hi @daperlman,

I don’t imagine the delay would have to be very long. The fact that the subscription API requests appear to be coming in tandem with the form submission is the issue. So long as the contact has been fully created before the opt-out requests are sent, it should be fine.

If you can reproduce the issue for existing contacts (so that we’ve eliminated the race condition as a possible cause) then please send me an example and I can dig into it further.