Breaking Change: Enhanced Validations for Non-String Properties in HubSpot's CRMObject APIs

[hseligson]

Starting January 6, 2025, HubSpot will implement enhanced validations for non-string property values, including enumeration and multi-value enumeration property values submitted via the CRMObject APIs. This change aims to improve data integrity and user experience by prohibiting leading or trailing whitespace characters, including invisible unicode characters, from these property values. Additionally, existing non-string property values and enumeration options will be backfilled to remove any whitespace or invisible characters from the beginning or end of all property values.

What's changing?

Stricter Validation for Non-String Properties

• Current Behavior: Enumeration values and other non-string properties that include leading or trailing whitespace characters, including invisible unicode characters (e.g., no-break spaces), are accepted and may lead to data inconsistencies or reporting issues.
• New Behavior: Non-string property values, including enumeration options and multi-value enumeration properties, must not contain leading or trailing whitespace or invisible unicode characters. Values with these characters will result in a 400 Bad Request error with a VALIDATION_ERROR category, providing details on the validation issues encountered.

Error Message Example:

{

"status": "error",

"message": "Property values were not valid: [{\"isValid\":false,\"message\":\"\"{{input_value}}\" includes leading or trailing whitespace.\",\"error\":\"LEADING_TRAILING_WHITESPACE\",\"name\":\"property_name\"}]",

"correlationId": "{{sample_correlation_id}}",

"category": "VALIDATION_ERROR"

}

Backfilling of Existing Non-String Properties

• All existing non-string property values and enumeration options will be backfilled to remove any whitespace or invisible characters from the beginning or end of all property values.

What does this mean for developers?

Ensure all data submissions via the CRMObject APIs for non-string properties, including enumeration options and multi-value enumeration properties, strictly adhere to the new validation rule. Developers should review and update any integrations, scripts, or automated processes that submit non-string property values to HubSpot to ensure compliance with the new validation rules.

Lastly, error-handling routines should be implemented or updated to manage responses from the CRMObject APIs that indicate invalid non-string property values due to the enhanced validations.

For example:

• Before the Change for Enumeration Options: If the valid enumeration options are ["one", "two", "three"], submitting a value like " two" (with leading space) or "two " (with trailing space) would be accepted.
• After the Change for Enumeration Options: Submitting " two" or "two " as an enumeration value will result in an 400 Bad Request error with a VALIDATION_ERROR response because it contains leading or trailing whitespace or invisible characters.
• Before the Change for Non-String Property Values: Submitting a property value like ‘“ 7”’ (a string with a leading space before the digit) would have been accepted.
• After the Change for Non-String Property Values: Submitting a value like ‘“ 7”’ or ‘“7 “‘ for a number property will not trigger a 400 Bad Request error, with the response indicating a VALIDATION_ERROR.

If you have questions or comments, join us in the peer-to-peer developer forums below.

[04838]

Do we have any update on getting this into non-production environments, this is crucial for testing.

Also the changelog ( https://developers.hubspot.com/changelog/breaking-change-enhanced-validations-for-non-string-propert... ) has this comment:

• "All existing non-string property values and enumeration options will be backfilled to remove any whitespace or invisible characters from the beginning or end of all property values."

This certainly indicates that somebody has some way to find all these occurrences.   Can we get those results for our existing environments?   If we have no occurrences of this, it  would be an easy way to avoid digging thru code and running tests to determine "if" we have the problem.

[hseligson]

Hi @04838 - 

Thank you for bringing up these concerns. We understand the importance of being able to test these changes in non-production environments, and we’re actively working on a solution that will allow for that. Our team is currently exploring options for making these validations available in a controlled manner, and we'll have more information soon.

We appreciate the suggestion regarding the backfilled values. We’re investigating the feasibility of providing more insights on this front, though there are a few technical and logistical considerations we need to work through. We’ll keep you updated as we make progress!

[04838]

Hello @hseligson is there any update on this issue?   Thank you.

[JGisoldo]

What happens if we send null for a non-string value?

[AndrewGallacher]

How can we test this before it goes live. Will it be switched on on sandboxes or other non-production portals before the change is deployed to all portals? 

[hseligson]

Hi @AndrewGallacher - Thank you for bringing up these concerns! As I commented above, we recognize the importance of being able to test these changes in a non-production environment, and we’re trying to work on a solution that will allow for that. Our team is currently exploring options for making these validations available in a controlled manner, and we'll have more information soon.