I’m trying to create a SQSSO for a client of ours that uses a simple URL query. However, I have two caveats here that are causing some trouble.
1) They want it through a Knowledge Base menu i.e. one of Hubspots integrated menu options. I don’t believe I can utilize JavaScript generated variables here as I have not had any functional responses, but can I use Hubspot generated variables via API calls? ({{contact.email}}, etc. )
and 2) If I can’t do either of these, is my alternative simply trying this through a Rich Text/HTML insertion elsewhere?
These also involve the use of a secret key which I will encrypt and attach to the query request. Are my thoughts on the right track here, and is this possible?
Hi there, @Kadranos -
It sounds like you are working on a clever integration for your client.
Setting up a Secure Query String Single Sign-On (SQSSO) using HubSpot’s native Knowledge Base menus can be tricky because these menus are primarily designed for static navigation.
Standard HubSpot navigation menus do not currently support the dynamic rendering of HubL variables (like {{contact.email}}) or JavaScript directly within the “URL” field.
Using a Rich Text module or a custom HTML snippet is a much more viable path. In a custom module or by editing the Knowledge Base’s footer/header HTML, you can use HubL variables to pull contact data. Please note that for {{contact.email}} to populate, the user must be a known contact with an active session or be viewing a page where HubSpot can identify them (such as a clicked email link).
Since this involves technical implementation and encryption, I’ve tagged some of our community experts to provide a more technical deep-dive into how you might bridge this with the Knowledge Base’s specific constraints.
@RubenBurdin, @DanielPicklo and @Mike_Eastwood — do you have any specific workarounds for passing encrypted contact data through a Knowledge Base navigation element?
Standard HubSpot navigation menus do not support dynamic evaluation of HubL variables (e.g., {{contact.email}}) nor the execution of JavaScript within the URL field.
A more robust approach is to leverage a Rich Text module or a custom HTML module. Within these, or by customizing the Knowledge Base’s header/footer HTML, you can utilize HubL variables to dynamically pull contact-specific data.
I hope this will help you out. Please mark it as Solution Accepted and upvote to help another Community member.
Hi @Kadranos , Gaurav and Seala already nailed the core limitation, so I’ll just reinforce it and add a bit of practical color from recent implementations.
You’re correct that HubSpot’s Knowledge Base navigation is static by design. Those menu URL fields do not evaluate HubL, do not execute JavaScript, and don’t support API calls at render time. Even in 2025, that hasn’t changed. So anything relying on {{ contact.email }} or a dynamically generated, encrypted query string will never work directly inside the KB menu config.
Where this does work reliably is at the template level. If you control the Knowledge Base header or footer HTML, or you insert a Rich Text / Custom HTML module inside KB pages, HubL will render there as long as the visitor is a known contact. From that context, you can safely construct the SQSSO URL server-side with HubL, including your encrypted payload, and present it as a button or link. That’s the cleanest and most supportable path. One thing to watch out for with LearnUpon SQSSO specifically is session state. If the user lands on the KB anonymously, {{ contact.email }} will be empty, even if they’re a customer. In practice, teams usually gate the KB behind login or ensure access via authenticated email links so HubSpot can reliably resolve the contact before rendering the SSO link.
If the “must live in the KB top menu” requirement is strict, there isn’t a true workaround. The usual compromise is a static menu item pointing to an intermediate KB page or system page where the dynamic SSO link is rendered correctly.
Your thinking around encrypting the secret and attaching it to the query string is sound. The constraint here is not security, it’s where HubSpot allows dynamic evaluation.
Hope this helps clarify the boundaries so you can pick the least painful option.