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


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?


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.


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?


Hi @xtrabytes,

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

{{|md5 }}


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?


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 }}


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?


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).


Thanks Derek. Very useful!