Challenge is that I want a 3rd party (non HS user) to be able to click in an automated contact-related email and that click will update a Contact property (status). How?
Best suggestion so far is to use a text field's code in the email to render a button loaded with a URL and the Contact's email address. The email is automated. This part I have made work.
Then the partner email recipient clicks the button and lands on a thank you page which as an HTML block hidden via some code - and this includes a HS form with email and status properties. The code here hides the form, autopopulates the email address, populates the status and submits the form. This is the part that doesn't work yet.
Nov 6, 20253:06 AM - last edited
2 weeks ago
by BérangèreL
Contributor
@auto-mate Creating a simple workflow with enrollment trigger of contact clicking a link in a specific email. Then editing the contact record by updating the property you wish to update. (In this case first name as an example.
Moderator note: While this solution may not address the original poster’s specific situation, it could be helpful for other community members facing similar challenges.
You’re absolutely right to be cautious. Exposing API keys or tokens in client-side code would indeed be unsafe.
However, the approach I mentioned doesn’t require that and is perfectly safe if done right. The key is to handle the API call server-side (which you can also do in WordPress).
Here’s how it would work:
The partner clicks the email link → it opens your thank-you page with a query parameter (ideally contact ID).
That page sends a lightweight request to your backend endpoint.
Your backend (not the browser) authenticates with HubSpot via your private app token and updates the contact. Credentials never leave your server.
This setup keeps the process secure and avoids the reliability issues of hidden forms or client-side submissions.
Did my post resolve your question? If so, please consider marking it as the accepted solution to help others in the community.
Instead of using a hidden form, you could directly send an API request to the Contacts API, since the contact’s email address is already available in the link (I assume as a query parameter). Simply add a bit of JavaScript to your thank-you page to trigger the request. No need for the hidden form.
That said, I recommend using the recordId in the query parameter instead of the email address, since it’s more secure, harder to guess, and mitigates potential data privacy concerns.
A quick reminder on security:
Don’t expose your API key in client-side code.
Allowing third parties to modify CRM data through exposed links is risky.
Ideally, protect this page behind authentication to prevent misuse.
"Security by obscurity" only works until it doesn’t 😄
Did my post resolve your question? If so, please consider marking it as the accepted solution to help others in the community.
Great reply Dennis. Thanks for the suggestion! I am well out my comfort zone here but if I get this correctly there are security issues here...
We looked at using the Contacts API directly, but seems unsafe — it would require exposing an API key or private app token in client-side JavaScript, which is a risk and would allow anyone with the link to modify (CRM) data.
Our current solution uses a hidden HubSpot Form submission instead. It’s secure (?) because the HubSpot Forms API doesn’t require authentication and only updates predefined fields. The downside is that it depends on client-side execution, and some browsers or WordPress configurations can block that script from running reliably.
I’m still looking for any way to make this more robust - well to make it work! - ideally a method that keeps it secure, doesn’t expose credentials, and runs consistently from a public thank-you page (and I am using a Wordpress page in this case).
You’re absolutely right to be cautious. Exposing API keys or tokens in client-side code would indeed be unsafe.
However, the approach I mentioned doesn’t require that and is perfectly safe if done right. The key is to handle the API call server-side (which you can also do in WordPress).
Here’s how it would work:
The partner clicks the email link → it opens your thank-you page with a query parameter (ideally contact ID).
That page sends a lightweight request to your backend endpoint.
Your backend (not the browser) authenticates with HubSpot via your private app token and updates the contact. Credentials never leave your server.
This setup keeps the process secure and avoids the reliability issues of hidden forms or client-side submissions.
Did my post resolve your question? If so, please consider marking it as the accepted solution to help others in the community.
Nov 6, 20253:06 AM - last edited
2 weeks ago
by BérangèreL
Contributor
@auto-mate Creating a simple workflow with enrollment trigger of contact clicking a link in a specific email. Then editing the contact record by updating the property you wish to update. (In this case first name as an example.
Moderator note: While this solution may not address the original poster’s specific situation, it could be helpful for other community members facing similar challenges.
The email recipient is not the Contact. B2B context, a business partner recieves the email, from a Contact based workflow - the Contact in question is a "lead" not the Partner. So, a simple workflow based on the "Contact clicking the CTA" won't work.
"native workflow logic is based on the recipient contact record, not another contact referenced in the email"
HubSpot’s workflow automation is built around the recipient’s (i.e., the Contact’s) interaction, not an external third party.
Since your partner (the email recipient) isn’t the contact whose property you need to update, the direct workflow and email click triggers won’t apply.
@auto-mate I may have missed a crucial point in the journey but could you not create a workflow with an email click as the trigger? That specific email and specific link to ensure enrollment accuracy? The workflow could then edit the contact record and required property?
This could still link through to a thank you page for the UX but not required hidden forms