topic Re: Announcement: Enhanced Field Validation in APIs & Integrations

Announcement: Enhanced Field Validation

jmclaren — Wed, 26 Feb 2020 16:06:51 GMT

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.

Re: Announcement: Enhanced Field Validation

MFrankJohnson — Thu, 28 Nov 2019 09:40:58 GMT

Any word on ...

- Which properties will be impacted specifically?

- Examples of the new validation rules?

- What "obviously wrong values" might be rejected?

Thanks in advance.

Re: Announcement: Enhanced Field Validation

jmclaren — Sun, 01 Dec 2019 20:18:24 GMT

Hi Frank,

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.

Re: Announcement: Enhanced Field Validation

TheresaB — Fri, 29 May 2020 13:00:54 GMT

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?

Re: Announcement: Enhanced Field Validation

davidwork7 — Wed, 13 Jan 2021 14:54:38 GMT

Dr.ing
D.Med
D.med
Dr.me
Dr.med.

above all text when i add in Firstname all time API give error

Can you give list or format which conider as Invalid TEXT

how can we ideantify its not valid text ?

Re: Announcement: Enhanced Field Validation

andreub — Fri, 20 May 2022 14:40:36 GMT

Hi jmclaren,

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?

Cheers

Re: Announcement: Enhanced Field Validation

jmclaren — Mon, 23 May 2022 13:26:41 GMT

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.

Re: Announcement: Enhanced Field Validation

jmclaren — Mon, 23 May 2022 13:33:08 GMT

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.

Client-side a helpful thing you can do is visually indicate to the user that the field is not complete when they leave off the area code. this can be done with the html `tel` input and CSS :invalid
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/tel

Re: Announcement: Enhanced Field Validation

Jaycee_Lewis — Mon, 23 May 2022 15:46:21 GMT

Thanks for the extra details @jmclaren 🙌 – Jaycee

Re: Announcement: Enhanced Field Validation

adriano-azos — Wed, 08 Jun 2022 15:39:23 GMT

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.

Re: Announcement: Enhanced Field Validation

PCronin9 — Mon, 27 Jun 2022 02:43:09 GMT

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.

Re: Announcement: Enhanced Field Validation

AHazelton — Tue, 12 Jul 2022 19:23:35 GMT

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.

Re: Announcement: Enhanced Field Validation

andreub — Thu, 26 Jan 2023 12:14:55 GMT

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.