Custom email preference page outside HubSpot with custom unsubscribe link ideally with hashed email in hubml


#1

I know we can build a custom pref page outside HubSpot using the API ( unless I overlooked something). What I don't know is whether the unsubscribe link in emails can be replaced to point to the external page, ideally encoding the subscriber's email in a URL query param. Is this possible and if yes, how?


#2

Hi @xtrabytes,

The default unsubscribe links can't be edited, and they can't be excluded from an email. You could create a custom link that went to your external unsubscribe page, but you would still need to include the default unsubscribe link in your emails in order to send them.


#3

Thanks a lot Derek! Is there a way to encode the email in a hashed way via Hubml ( even Base64 would be ok) to be inserted into an external link?


#4

Hi @xtrabytes,

HubL has an md5 filter, that calculates the md5 hash of an object. You could do the following:

{{ contact.email|md5 }}


#5

Thanks Derek. MD5 is not useful as I need a bidirectional hash. Doesn't need to be encrypted, just not plain text. So I thought base64 would be an option. So md5 is the only close candidate you think?


#6

Hi @xtrabytes,

That's the only hash that's supported in HubL, so you'd need to find a way to do the hashing yourself if MD5 won't work. You could possibly store a base64 hash of your contacts' email addresses as a custom contact property, and then include the hash in your emails in the same way I mentioned above:

{{ contact.custom_hash_property }}


#7

I see, that's an interesting approach. Can you point in the right direction how to do that? I assume that has to be done by an outside service/app via the Contacts API?


#8

Hi @xtrabytes,

That's right; I've included resources below on creating a custom contact property and updating a contact property via the Contacts API. To automate the process, you'd want to use either a workflow webhook action (for a simple solution) or the Webhooks API (for a more extensible solution). I've included docs for both below as well.

Lastly, you'd need to actually write/host the app externally. I don't have as many recommendations on this front; if you have an existing server hosting solution, I'd recommend taking advantage of that. Otherwise, you might consider simple solutions like Heroku, AWS, of Google app engine (see below).


#9

Thanks Derek. Very useful!