Nov 26, 201910:51 AM - last edited on Feb 26, 202011:06 AM by zwolfson
HubSpot Employee
Announcement: Enhanced Field Validation
SOLVE
EDIT: This change has started to take effect. We'll be rolling this out gradually over the next week
What’s Changing?
HubSpot is changing how validation works on some commonly used fields for contacts, including the first and last name. This change will look for values that are obviously not valid values for the fields.
Why are we making this change?
This change should help HubSpot customers maintain a cleaner database by rejecting obviously wrong values from being added to properties. This change is also designed to help protect customers from attack. By restricting the values of commonly used fields, it makes it more difficult for attackers to inject potentially harmful values.
What action is required?
For the vast majority of developers, no action is required. However if you are using the default fields for a purpose other than their original intent, you should create a custom property to hold this information.
When will this change take place?
This change will take effect on February 26, 2020.
If you have any questions, join the discussion below.
Unfortunately we can't provide the pattern/code which is used to validate values. While understandable to want that as an integrator, we would them be also providing that information to spammers or bad actors defeating the purpose.
What I can tell you is the validation is looking for obvious wrong answers. Without explicitly stating a real example. Imagine you have a number field, and someone submits letters. That would be an example of an obviously wrong answer.
Good questions, affected fields/properties are standard HubSpot default fields. An example of both a validation rule and obviously wrong value, would be if you have a first name field and a URL or code was entered instead.
If you have been intentionally storing data this way we would advise using new custom properties rather than abusing the default properties.
would it be possible to obtain a description of the pattern or algortithm that determines the validity of values, so that we can know beforehand whether a value will be accepted by the API or not?
Unfortunately we can't provide the pattern/code which is used to validate values. While understandable to want that as an integrator, we would them be also providing that information to spammers or bad actors defeating the purpose.
What I can tell you is the validation is looking for obvious wrong answers. Without explicitly stating a real example. Imagine you have a number field, and someone submits letters. That would be an example of an obviously wrong answer.
This is aggravated by the fact that the error message is not easily parseable. If you update several contacts in batch and one of them contains an "obviously wrong" name, the error response will tell you which field was the offending one, but not of which contact. As far as we've seen, the only way to find exactly which name has a problem is to parse the error message, which used to say "\"foo.bar\" contains a URL". Now the message changed to "foo.bar contains a URL" (note no quotes anymore) and that broke our workaround.
So, if the API is going to reject input following unpublished rules, it'd be nice if at least the rejection message follows a standard format so we can do something about that.
Is there a way to perform some validation prior to creating the contact so that the user can update the input prior to submitting the request? For our integration, the Hubspot contact creation happens later on in our workflow after our own validation is performed. Without providing any validation rules, we have no way of knowing if this step is going to be successful. Please either make this feature optional or provide some way of validating the input without creating the contact.
I found this surprising; at least for our use case. Are any of the "obviously wrong" characteristics being checked for on the list of falsehoods programmers believe about names? From our perspective, if someone says their name just happens to also parse as a hostname, that's fine, it's not our business to tell them they can't have that name. I guess using a custom property to replace HubSpot's name field will work for our organization, but it'd be lovely if the things a text field called "name" won't accept were at least described somewhere in the API docs so that a lot of trial an error on the part of many integrators could be saved.
Does this mean that if I set the pattern attribute on input by javascript, it does not work inside the HubSpot form? I'm trying a lot an input with a pattern that doesn't work.
I am having issues with one of my clients because prospects are not all including their area code when inputting a phone number. Is there any way for phone numbers to be validated?
Hey there, understand the frustration. If you're using the API and collecting the phone number yourself I recommend building your integration so that it requires the user to submit an area code.