URL Encoding issue on custom url with email.

Highlighted
New Contributor

Hi there.
We are attempting to send an email through hubspot that allows the user to confirm their email in OUR platform we developed.

 

We created a contact property we populate with the custom URL and insert that into an email via a personlization token. We then automatically send that email to the user when we see it is populated.


The issue we are running into is that the URL encoding of that link once is has been sent to the user breaks. The email pulled from the contact would look like this, `test+1@gmail.com`. The encoded email in the URL appears as `test%201%40gmail.com`. That `+` character should be encoded as `%2B`. Is there something wrong we are missing?

The closest forum help I've found is https://integrate.hubspot.com/t/script-contact-email/8390

0 Upvotes
5 Replies 5
Highlighted
Top Advisor | Platinum Partner

You're not missing anything, unfortunately, it looks like HS might not be encoding the query part of the URL separately from the pre-query. Anytime there is a + sign after the question mark, it is considered a space.

I believe jinja requires a custom filter to convert plus sign to %2B so, they may need to add that to their own codebase internally.

I'm fairly certain you found a legit bug and should consider submitting it. 

Highlighted
New Contributor

I'd talked with hubspot support and indeed there is a bug. They are looking to resolve. In the mean time on our side we will have to convert the %20 to %2B so + will work. This is possible only because %20 (a space character) is illegal in email addresses.

Highlighted
New Contributor

Currently facing the same issue with our custom URL.  Any update on this bugfix?

Highlighted
Community Manager

hey @itsvla,  I am not seeing anything related to fixing the encoding issue here, but I am still looking.  I will update this thread if I find something of use.

 

Thanks!

 

Thanks,

Dennis


We are excited to announce that the Community will be launching a weekly newsletter on November 2, 2020!
Sign up today!
Highlighted
Community Manager

Heya all!

Just an update here on the reason there has not been a fix for this specific issue.  

 

The reason is that there is no way for us to know when creating URLs that we should be encoding the *+* versus treating it like a space. If we were to attempt to maintain *+* signs in all URLs, there is a chance that we may introduce unintended bugs with URLs that rely on it being treated as a space.  

 

With that being said, we have explored this several times. If there is a solution, I will make sure to add to this post.

 

Thanks,

Thanks,

Dennis


We are excited to announce that the Community will be launching a weekly newsletter on November 2, 2020!
Sign up today!