Get email subscription status not returning correct data

Johnboy1 · ‎May 10, 2018

We are using the email subscription status documented here: https://developers.hubspot.com/docs/methods/email/get_status

To find out which mailing lists a user is subscribed to and display it to them on our website and allow them to unsubscribe using https://developers.hubspot.com/docs/methods/email/update_status.

We have noticed however that initially, the get_status will not return any subscriptionStatuses, despite users being subscribed to multiple lists.

{
    "subscribed": true,
    "markedAsSpam": false,
    "portalId": REDACTED,
    "bounced": false,
    "email": REDACTED,
    "subscriptionStatuses": [],
    "status": "subscribed"
}

If the user clicks the "Subscription Preferences" link in the bottom of an email (sent to them as they ARE subscribed to a list) they are shown a page on Hubspot. This page shows the user as being subscribed to several lists but the API will still return none.

If the user submits the form on this subscriptions preferences page and we then make the API request again then preferences are then returned.

{
    "subscribed": true,
    "markedAsSpam": false,
    "portalId": REDACTED,
    "bounced": false,
    "email": REDACTED,
    "subscriptionStatuses": [
            {
                "id": REDACTED,
                "updatedAt": 1525774120864,
                "subscribed": true,
                "optState": "NOT_OPTED"
            },
            {
                "id": REDACTED,
                "updatedAt": 1525774120864,
                "subscribed": true,
                "optState": "NOT_OPTED"
            },
     ],
    "status": "subscribed"
}

I was informed to post the problem here as apparently the Hubspot support team are unable to report such issues with their product themselves.

I was also fobbed off with a claim that

We won’t include an entry for a subscription type until the contact unsubscribes from that type.

Which is simply untrue as shown in my example above active subscriptions are returned and this user had not unsubscribed from anything, simply resaved their preferences.

Derek_Gervais · ‎May 22, 2018

Hi @Johnboy,

First, I want to make sure to explicitly call out the distinction between an email address' subscription status and a blog subscription list. These are discreet; a smart list in your portal does not necessarily reflect the subscription status of a particular email address in the sense we've been discussing here.

Second, I'd like to address the following:

The responses we have received from Hubspot on this matter seem to suggest we should assume a user is subscribed to all lists except where the subscription status API returns false.

You can think of the three possible subscription values like this:

true - The contact has explicitly opted in to receiving this type of email
false - The contact has explicitly opted out of receiving this type of email
null - The contact has not explicitly opted either in or out of receiving this type of email

We do not recommend broadly that all contacts without an explicit opt out should be treated as opted in. However, contacts with subscription types that are null are distinct from those set to false; one is explicitly opted out, while the other has not explicitly opted in/out.

Third, it's important to note that changes have been made (and will continue to be made) regarding HubSpot's GDPR-related functionality. Regarding what a user (in this scenario, referred to as Anna), this is pulled from our GDPR Playbook:

The box for a given subscription type will be checked if she’s opted in and unchecked if she’s either neutral (not opted in or out) or opted out.

Also, regarding knowing which lists are / are not subscribed to:

If the GDPR toggle in your settings is disabled, you’ll be able to send to your entire list (save for the opt-outs) --- regardless of whether you have lawful basis to communicate with the contacts on the list.
If the GDPR toggle in your settings is enabled, you’ll only be able to send to contacts for whom you have lawful basis to communicate (via your subscription types) --- either via consent, or otherwise. If you don’t have lawful basis to communicate for certain contacts on the list, you’ll be alerted.

Like I mention above, there are some aspects of the old functionality that can cause confusion with regard to GDPR compliance. Even some parts of my previous posts are now outdated with the recent GDPR-related updates. I recommend digging deeper into our GDPR playbook for more clarity on the specifics of these scenarios; I've included a link to the playbook below:

Johnboy1 · ‎May 21, 2018

Hi @Derek_Gervais,

Today a member of our marketing department set up a new blog. This automatically created a mailing list for the blog which was returned by the subscriptions type API you referenced.

This list is empty, a brand new list which nobody is subscribed to it at all. The responses we have received from Hubspot on this matter seem to suggest we should assume a user is subscribed to all lists except where the subscription status API returns false. In such a scenario we would then be assuming the user was subscribed to this new blog mailing list and listing it on their preferences page causing them alarm that they have been added to a mailing list without the explicit consent and thus a breach of GDPR.

Can you advise if there is any definitive way to work out which lists a user is actually subscribed to?

Jon_Milsom · ‎May 15, 2018

Hi Derek,

Thanks for the response, I believe the confusion stems from HubSpot's use of null in the API response.

Unfortunately, @Johnboy is on annual leave at the moment but I believe we have enough information to provide a solution by using the "get email subscription types" endpoint. I will assign this to another developer in his absence.

As a general comment, this does seem like a strange method of operation from a technical point of view (null, true, false). I understand that your application architecture may dictate how this works but I don't see why your API could not abstract this complexity before returning a response. Perhaps something to consider on your product roadmap?

Thanks again,
Jon

Derek_Gervais · ‎May 14, 2018

Hi @Johnboy,

I'd first like to clarify the statement:

We won’t include an entry for a subscription type until the contact unsubscribes from that type.

This isn't exactly accurate, as you've seen. The value for a specific email type is either true, false, or null. True and false are self explanatory, but null is more confusing. More accurately:

A null value in this circumstance signifies a contact whose subscription preferences have never been changed, and therefore are not opted out of that type.

When your user updated their email preferences, HubSpot saved the email address' subscription preferences explicitly. There are a couple of considerations here;

First, you shouldn't currently count on an email address' subscriptions to include explicit values for all email types, since null values will be excluded. You can get the complete list of email types via the 'Get email subscription types' endpoint (see below).
Second, HubSpot is still making product updates regarding GDPR compliance. The best resource to stay updated on that front is our GDPR product readiness page (see below).

Let me know if you have any other questions related to the currently functionality!

Johnboy1 · ‎May 10, 2018

With the looming GDPR deadline, it is vital that we give users a way to be able to unsubscribe from these lists. Currently, the only thing to do is to ask them to

search their inbox for previous mailings and click the Subscription Preferences link

Clearly, this is not really an acceptable way forward

APIs & Integrations