We’ve been dealing with a wave of spam form submissions over the past few weeks and after digging into it, found something worth sharing, especially for anyone using embedded HubSpot forms via a custom code snippet (e.g. through Webflow or similar).
What we noticed: Contacts appearing in HubSpot with gibberish names (think: rbRDAhaFWjbdhKBPFDINQFU ssXflhuHLGtdyoPSJzq), dotted Gmail addresses, and sometimes even legitimate corporate domains being spoofed (e.g. someone@realcompany.com). All showing as direct traffic, 0 page views, 1 visit.
The twist? reCAPTCHA is already enabled on our forms. Our developer confirmed that Webflow is capturing clean data (not capturing any spam submission at all), the spam is bypassing our front-end entirely and hitting the HubSpot API directly.
In that case, this is completely out of HubSpot’s hands. It’s a third-party form which HubSpot is making available “out of courtesy”, HubSpot does not control a single part of that form. If you want HubSpot’s spam detection features, then you would have to switch to a HubSpot form, as far as I know.
Your Webflow observation is the important clue here: if Webflow is not seeing the spam at all, the requests probably are not touching your page. In that case this usually is not a page-reCAPTCHA problem; it is a HubSpot Forms API path problem. Once a bot has the portal ID + form GUID, it can post directly to HubSpot and skip Webflow, page JS, WAF rules, and page-level CAPTCHA entirely.
The awkward part is that HubSpot’s own form-level CAPTCHA is also an all-or-nothing control. It is one of the few things direct API submissions hit, but HubSpot also rejects legitimate server-side forwarding into a CAPTCHA-on form with FORM_HAS_RECAPTCHA_ENABLED, so it can break the same integrations you might put in front of the form.
The pattern I would look at is structural: route public submissions through an endpoint you control, forward clean ones into a hidden HubSpot destination form, hold risky ones in quarantine, and then retire/archive the old public form once you have checked downstream workflows and reports. De-embedding the old form stops new GUID exposure, but if the old GUID is already known, closing or archiving that old form is what actually removes the direct path.
I’m working on a small HubSpot Forms-specific tool around exactly this setup. Basic version uses the forms scope only, not contacts read/write. Happy to share the setup checklist if useful.