Inconsistency in recent_conversion_event_name Field Across Form Types and Hosting Regions

Apps Third-Party Apps
1

We’ve observed inconsistencies in the propertyValue of recent_conversion_event_name field, which is received via webhook events under property changes. According to the documentation, propertyValue field contains the form name; however, in practice, the values vary depending on form type and data hosting region.
Here are some examples of the inconsistencies we’ve noticed:

  1. Standard HubSpot Forms (US West Region: URL : https://app-na2.hubspot.com:disappointed_face: The value is prefixed with "Form: ", e.g. “Form: Contact Us”.
  2. Standard HubSpot Forms (US East Region URL : https://app.hubspot.com):The prefix is absent, e.g., “Contact Us”.
  3. Pop-up Forms: The value often includes a prefix based on the page title or context, e.g. “Get a Quote - Homepage”.
  4. Non-HubSpot Forms: The value often includes a prefix based on the page title or context e.g. “Mailmodo : Helping marketers build interactive emails: #custom-hubspot-form”.

These dynamic and inconsistent naming conventions are making it difficult to reliably interpret the field across different use cases.

Could you please clarify whether there is a consistent pattern or recommended way to interpret or normalize the recent_conversion_event_name field values across regions and form types? If there is an underlying identifier or method to consistently map this field to the actual form record, that would be helpful to know.

2

Hey, @santosh_dangi :waving_hand: Thanks for your feedback. Please note, this is a peer-to-peer support forum where community members help each other. HubSpot Support and Engineers do not post here regularly.

In your case, this is working as designed, but not as you expect. Meaning, the naming conventions are not likely to be customizable in the manner you need them to be. This is a challenge, as you know, because of having to rely on webhooks to get updates for form submission data. The naming for non-HubSpot forms is based on the CSS Class or ID attribute of the non-HubSpot form.

Likely, external processing is necessary if you require more consistent naming formatting. I know this is not the answer you are after. And we’ll leave this here in case other community members have any feedback for you.

Best,

Jaycee

3

Hi @santosh_dangi

I’ve seen the same thing. The recent_conversion_event_name field isn’t standardized across regions or form types, and HubSpot doesn’t normalize it. The documentation

(Accounts Dashboard | HubSpot)

Confirms the field returns the “form name,” but as you noticed, in practice that can include prefixes like “Form: ”, page titles, or even CSS identifiers depending on the source.

A common workaround is to treat this property as descriptive only and instead rely on the underlying form identifiers. You can pull the formId via the Forms API

(Accounts Dashboard | HubSpot)

Or through submission payloads, which gives you a consistent key to map against your own naming convention. From there, you can build a normalization layer that maps all these varying labels back to a canonical form name in your system.

For teams that need consistency across multiple systems, one practical approach is to process the webhook payload externally: strip known prefixes, fallback to formId, and store your own clean label for reporting. That way you don’t depend on HubSpot’s varying naming logic.

If you’re dealing with multi-system integrations where data consistency is critical, I’d mention we actually built Stacksync for this kind of challenge.

It uses real-time two-way sync with field-level change detection, so instead of wrestling with webhook name quirks, you can map stable identifiers once and keep everything aligned automatically across HubSpot, databases, or ERPs.

In practice, it cuts down on the glue code and saves engineering teams weeks of maintenance.

Hope this helps.