Forms API(s) expose email field with empty validation properties

[Lars-Erik]

I have some weird behavior with the Forms API. It seems to decide per form whether the validation information of the email property (at least) should be included. I first thought it differed across portals, but now find that it differs between forms. It does not matter whether I use V1 or V2.

I get this from one of the first forms we ever made in our portal:

    {
        "validation": {
            "blockedEmailAddresses": [],
            "name": "email",
            "message": "Please enter a valid email address",
            "data": "",
            "useDefaultBlockList": false
        },
        "dependentFieldFilters": [],
        "labelHidden": false,
        "propertyObjectType": "CONTACT",
        "name": "email",
        "label": "Email",
        "type": "string",
        "fieldType": "text",
        "description": "",
        "groupName": "contactinformation",
        "displayOrder": 2,
        "required": true,
        "selectedOptions": [],
        "options": [],
        "enabled": true,
        "hidden": false,
        "defaultValue": "",
        "isSmartField": false,
        "unselectedLabel": "",
        "placeholder": ""
    }

But this for other forms, including fresh ones in new customer portals:

    {
        "validation": {
            "blockedEmailAddresses": [],
            "name": "",
            "message": "",
            "data": "",
            "useDefaultBlockList": false
        },
        "dependentFieldFilters": [],
        "labelHidden": false,
        "propertyObjectType": "CONTACT",
        "name": "email",
        "label": "E-post",
        "type": "string",
        "fieldType": "text",
        "description": "",
        "groupName": "contactinformation",
        "displayOrder": -1,
        "required": true,
        "selectedOptions": [],
        "options": [],
        "enabled": true,
        "hidden": false,
        "defaultValue": "",
        "isSmartField": false,
        "unselectedLabel": "",
        "placeholder": ""
    }

I cannot for the life of me spot _any_ difference between the forms / fields. Have checked whether changing the label for that second one helped, but it didn't.

Also, the blocked domains list is excluded from both responses.

Both forms validate nicely, and create an "email" type input when I view the form in HubSpot. (Also think the "type" returned by the API should say "email")

To me this seems awfully lot like a bug in the API(s)?

[WendyGoh]

Hey @Lars-Erik,

Could you share with me:

1. Your portal ID and customer portal ID.youtube

2. An example page that your form is on and an example page that your customer form is on.

3. A snippet of the code on your portal and on customer portal.

4. An example of an email address that was invalid.

[Lars-Erik]

Hi Wendy,

This is via the API, not any HS JavaScript/embedded/cos/blog things.

These two API calls to our portal (436498) can be used to debug:

Provides e-mail validation info:

https://api.hubapi.com/forms/v2/forms/05d78774-0bc2-4a84-8ce5-e0eff735e2aa?hapikey=[our api key]

Provides blank validation info for e-mail:
https://api.hubapi.com/forms/v2/forms/6bc1eaea-0a8f-4033-9015-43ae8cacb457?hapikey=[our api key]

Lars-Erik

[WendyGoh]

Hey @Lars-Erik,

Thanks for sharing these information across. 

We have reach out to our internal team to check on this and I'll keep you posted as soon as possible here! 

[Lars-Erik]

Thanks!

[WendyGoh]

Hey @Lars-Erik,

Here's an update! 

Currently, the "message" property has been depreciated and should not be used.

Some form may still appear with the property set because that were either created a very long time ago or created with the old CMS form field.

I hope this helps to shed some light! 

[Lars-Erik]

Thanks, @WendyGoh.

Does that mean that we no longer get any information about validation via the Forms APIs?

I can't see anything else indicating validation.

This is horrible. 😭

Lars-Erik

[Lars-Erik]

On a sidenote, we don't really care about the validation.message property, we care about the validation.name property.

[WendyGoh]

Hey @Lars-Erik,

Do you mind sharing further with me your team use case in which your team had like the ability to retrieve validation information? 

[Lars-Erik]

@WendyGoh, we have several non HubSpot sites where we generate form HTML serverside to make the markup and styling more uniform with the rest of the sites. As well as extend the forms in some cases. We then use the form API to submit the responses back to HubSpot. In some cases we also want to intercept and process the submissions.

I must admit that I don't see any reason why I should justify using the API and how you can justify removing important information from the API results?

Lars-Erik

[WendyGoh]

Hey @Lars-Erik,

In this case, could I clarify further if you're looking to show custom validation messges? If so, this documentation How to customize the form embed code outlines how your team can change validation messages. 

[Lars-Erik]

Sorry @WendyGoh, but I'm starting to wonder whether you understand what I'm saying at all. We do not use the JavaScript embed version. We are using the Forms API to do our own server-side rendering of forms, and then we need to apply other mechanisms for validation. The fact that the API does not include information other than "required" with the API responses means it is broken. This is by definition a bug report and I'm very disappointed you are not taking it serously.

Lars-Erik

[WendyGoh]

Hey @Lars-Erik,

Thank you for the further clarification. 

I apologise if I came across as not taking this seriously, I was trying to understand your team's use case to identify the pain point. 

Just to make sure that we're on the same page now, I'd like to share my understanding of your use case:

Based on my understanding, your team is using the Forms API (specifically this - Submit data for a form endpoint) to make HubSpot form submission and your team is also using the Get a form by its unique ID endpoint to retrieve the validation messages so that you can use it on your external validation mechanisms. Am I understanding this correctly?

[Lars-Erik]

Indeed. I would presume that was clear from the OP, since I pasted obvious responses from those APIs there.

Soz for being non-constructive, I'm just surprised it wasn't obvious.

[WendyGoh]

Hey @Lars-Erik,

I check in further with my team and I'd like to reassure you that we are not removing email validation on the Submit data for a form | Forms API. You would still always get this message: 

name:"email",label:"E-postadresse",type:"string",fieldType:"text",description:"",groupName:"contactinformation",displayOrder:-1,required:true,selectedOptions:[ ],options:[ ],validation{pinname:"",message:"",data:"",useDefaultBlockList:false,blockedEmailAddresses:[ ]},

*which is the default one

The form where you mentioned that your team is not seeing, is a edge case and if your team want consistency, what you can do is remove the email field and re-add it back on the form. That should be enough and going forward, you will still going to receive an error like this when there's an validation error on the email field:

name:"email",label:"E-postadresse",type:"string",fieldType:"text",description:"",groupName:"contactinformation",displayOrder:-1,required:true,selectedOptions:[ ],options:[ ],validation{pinname:"",message:"",data:"",useDefaultBlockList:false,blockedEmailAddresses:[ ]},

[Lars-Erik]

I don't care whether you validate on the HS-side when we submit the forms, I care that I get information about the validation when we fetch the form information using the API described here: https://developers.hubspot.com/docs/methods/forms/v2/get_form.

It cannot be an edge case, we've tested several forms and 8/10 seems to have this problem. It goes for forms that's been in our own portal for years, and new forms in portals created this spring. We cannot go through forms on all our customers' portals and re-add fields just because you have bugs in the APIs. 

This is a totally unacceptable anwer.

[WendyGoh]

Hey @Lars-Erik,

Let's take a step back here. I understand that your end goal is: 

Your team had like to use the Forms API (specifically this - Submit data for a form endpoint) to make HubSpot form submission and your team would like to use the Get a form by its unique ID endpoint to retrieve the validation messages so that you can use it on your external validation mechanisms.

With this end goal in mind, I'd like to share one thing across:

For forms created awhile back/created with the old CMS form field, the validation message will display the following for the email field:

Please enter a valid email address

The other form fields will not have a validation message. 

As such, if your team is looking to extract the validation message for the email field, would it be easier for your team to save this validation message as a variable in your system as opposed to calling the Get a form by its unique ID endpoint to retrieve the validation message each time a form submission is made? 

Having said that, if the above doesn't work for your team, I was thinking would it be easier for us to hop on a call to explain things further? 

[Lars-Erik]

Happy to hop on a call monday 15 CET. lea at markedspartner dot no.

[Lars-Erik · Accepted solution]

So after talking through this, we've idenfied e-mail fields as the most prominent feature that lacks validation metadata at the moment. An intermediate solution is to "hack" our solutions and look for the built-in name "email". HubSpot does not have a mechanism to tag other fields as e-mail types at all, so that would not work in any case.

Dates and numbers have their own field types, so those can still be validated.

I've added a request to the ideas forum where I describe the need for a first-class e-mail property type as well as a few other suggestions.

Hope this is taken seriously as I'm confident we're not the only company doing this. I'm sure there are annoyed customers out there who just doesn't tell you. 😉

Here's a link to the suggestion:

https://community.hubspot.com/t5/HubSpot-Ideas/Add-a-property-type-for-email/idi-p/346974#M59157

[WendyGoh]

Hey @Lars-Erik,

Thanks for sharing your use case. I apprecaite it. 

The reason I asked for your use case is because I'd like to understand further the use of the validation property and had like to shed more lights with my internal team. 

In this case, I've pass along your use case with our internal team and is looking to see if there's any other workarounds for this. I'll keep you updated here!