Breeze intelligence and custom CSS

Developer Support
1

I’m trying to use Breeze form shortening on a demo form embedded on our site, and I’ve hit what looks like a conflict between shortening and custom styling.

Here’s what I’m seeing:

Form shortening only works on the new-style embed (js-na2.hsforms.net/forms/embed/<portalId>.js with the hs-form-frame div). It runs fine there, enrichable fields hide for known business emails like they should. The problem is that embed renders the form inside a cross-origin iframe (js-na2.hsforms.net/...frame.html), so none of our custom CSS reaches the form fields. I can only style the outer container.

The classic hbspt.forms.create() v2 embed renders inline with no iframe and takes custom CSS fine, but from what I can tell form shortening doesn’t run on that older embed.

So it feels like an either/or: shortening with the iframe and no custom CSS, or full custom styling with the inline embed and no shortening.

A few questions:

  1. Is there any embed method where shortening runs and the form is inline (not iframed) so I can style it with my own CSS?
  2. Does the “export raw HTML form” option still run shortening once it’s embedded, or does exporting break the enrichment behavior?
  3. If neither works, what’s the recommended way to get an embedded shortening-enabled form to match a custom design? Is styling basically limited to whatever the in-app form editor exposes?

We need to keep a specific visual design on this form, so figuring out what’s actually possible would help a lot. Thanks.

3

Hey @Devik,

Welcome back! :partying_face:

Great questions and thanks for all of the details! These types of conflicts between embed methods and custom styling can definitely be tricky to navigate.

There are a few moving pieces here around how Breeze shortening interacts with different embed types, and the answers may vary depending on your specific setup. While we wait for others from the community to chime in, here are a few community threads that might point you in the right direction:

  1. Custom CSS to new HubSpot forms
  2. Form padding
  3. New Form Editor

Tagging in a few folks who may have hands-on experience with this:

Hey @alyssamwilie, @Alex_Boissonneault, @GRajput – do you have any suggestions for @Devik on this?

Thanks in advance!!

Sam, Community Manager

4

Hey @Devik, thanks for looping me here @stassey!

I can see, your either/or read is correct, there’s no embed today that gives you both. But let me answer your three directly:

1. Inline embed with shortening? No. Shortening only runs on new-editor forms, and the new embed is iframe-only on external sites. There’s no inline variant of it.

2. Raw HTML export? Moot, unfortunately! raw HTML export only exists for legacy editor forms, and those can’t have shortening at all. HubSpot’s own docs confirm the updated editor doesn’t offer it. So it’s not that exporting breaks enrichment; the option doesn’t exist for a shortening-enabled form in the first place.

3. What I’d actually do - depends how strict “specific visual design” is:

If it’s close-enough territory: the new editor’s style panel + brand kit gets you further than people expect (fonts, colors, spacing, radius, button styles), and you can style the outer container for width/positioning. That’s the ceiling for the iframed form, so exhaust it first.

If it’s pixel-perfect and non-negotiable: build the form yourself and submit via the Forms API, then replicate the shortening UX with your own logic, on email blur, hit your backend to check if the domain/contact is known (your CRM via API, or an enrichment vendor) and hide the enrichable fields. It’s more work, but it’s the only path to full CSS and a shortened experience today, because Breeze enrichment has no public API you can wire into a custom form.

One caution: you’ll find scripts that reach into the form DOM to inject CSS, they don’t work here, the new embed’s iframe is cross-origin by design. Don’t burn time there.

And do drop “custom CSS / raw HTML for new-editor forms” on the Ideas board, it’s one of the most-asked gaps since the new embed shipped, and shortening being locked to it makes the case stronger.

5

Hey @Alex_Boissonneault, thanks for the detailed reply earlier, that saved us from chasing dead ends.

One follow-up on the embedded (shortening-enabled) form: on our current custom form, when someone submits we swap the form for an inline Calendly widget (prefilled with their name/email) so they can book right there, no redirect.

With the embedded form rendering inside the cross-origin iframe, can the parent page still catch the submit (via onFormSubmitted / hsFormCallback) and render our own Calendly widget in place of the form? Or is the post-submit experience limited to the success/thank-you state configured inside the HubSpot form itself?

Thanks again.

6

this one actually works, and it’s cleaner than the old way.

New-editor forms don’t use the old hsFormCallback postMessage stuff (that’s why every snippet you’ll find for it seems broken). Instead, the embed script dispatches DOM events on the parent window, even though the form itself renders in the cross-origin iframe. The one you want:

js

window.addEventListener("hs-form-event:on-submission:success", (event) => {
  // event.detail carries formId + instanceId — check it's this form
  // then hide the .hs-form-frame container and mount Calendly
});

There’s also on-ready and on-submission:failed if you need them. One caveat straight from the docs: register any on-ready listener before the embed script runs, or you’ll race it.

For the Calendly prefill: the success event payload only carries formId/instanceId, not the submitted values. But the same forms JS API exposes getFormFieldValues on the form instance, grab email/name from there when the success event fires (works for everything except file fields), then pass them into your Calendly init exactly like you do today.

So your flow survives intact: listen for the success event > pull the values > swap the frame for the inline Calendly widget. No redirect, and the thank-you state inside the form never even shows.

Full reference here: Global form events, it is worth a bookmark, it’s easily the least-discovered forms doc HubSpot has.

7

thank you!!