Inconsistent email validation using Forms API

[celston1n]

This is directed mostly at HubSpot developers but if anyone has previous experience, any information would be helpful.

We are sending requests to the Forms API v3. Some of our tests are being rejected for "invalid email". We are intentionally using emails containing date/time so we can differentiate them from others. However, they are valid by RFC standard. Here's an example:

4264 15:06:46 INFO strEndpointURL: https://api.hsforms.com/submissions/v3/integration/submit/[PORTALID]/[FORMID]
4264 15:06:46 INFO strFormData: {"fields":[{"name":"firstname","value":"Testy"},{"name":"lastname","value":"McTesterson"},{"name":"email","value":"test20181002_1506@test.com"},{"name":"company","value":"Test Inc."},{"name":"page_type","value":"Contact Us"},{"name":"message_website","value":"Disregard."},{"name":"industry_dropdown","value":"Aviation"}],"legalConsentOptions":{"legitimateInterest":{"value":true,"subscriptionTypeId":"342621","legalBasis":"LEAD","text":"Consent to communicate for subscription type ID 342621"}}}
4264 15:06:48 ERROR Failed web request: {"status":"error","message":"The request is not valid","correlationId":"36a102fe-418a-4f91-9e77-d58a6753d132","errors":[{"message":"Error in 'fields.email'. Invalid email address","errorType":"INVALID_EMAIL"}],"requestId":"44ea2422faf5f321dec0bd896601e8bd"}

Other emails we see in the system submitted through the same means contain numbers, underscores and the domain test.com with no issues. Can we say with conviction what the problem with this particular address is? Can we be assured we are not going to have problems with real-world users? Are there standards beyond RFC that you are checking?

[IsaacTakushi · Accepted solution]

Hey @swoopamir,

With validation disabled, none of the checks I mentioned above will be processed:

1. Formatting check : The text must look like an email address and the top level domain must appear in a public suffix list.
2. Domain blacklists : HubSpot maintains a list of throw-away email domains, like lasersharks.com .
3. DNS Lookup : The domain of the email address must have an MX record or an A record.
4. HubSpot Data Check : The email must not be globally blocked.
5. HubSpot Delivery Check : If HubSpot has ever delivered an email to the address, then the email is considered OK without continuing.

While I can't say with certainty, you may see more submissions with improperly formatted email values (e.g. asdf1234), but the good thing is these submissions won't create new contact records.

The form won't check whether the address belongs to a valid domain, so you may also see "fake" submissions coming through (e.g. testhippo@yugioh.com).

On the other hand, all freemail addresses like gmail.com and yahoo.com will come through without the inconsistent filtering you cited earlier, so I'd recommend monitoring your submissions closely before fully committing one way or another.

[IsaacTakushi]

Hey @swoopamir,

If you're using "skipvalidation": false, then validation is on, so there shouldn't be any downside.

[#4]

@Isaac_Takushi youre right, sorry i meant if i have skipvalidation on True

[IsaacTakushi]

Hey @swoopamir,

Can you confirm you included "skipvalidation": true?

I successfully submitted those first two emails using the v3 endpoint using "skipvalidation": false and only ran into issues with the last. When I switched validation to true, however, the last email was accepted:

Screenshot 1.jpg767x473 54.7 KB

Screenshot 2.jpg763x472 54.4 KB

Screenshot 3.jpg765x617 79.5 KB

Screenshot 4.jpg763x477 57.8 KB

[#6]

Skipvalidation worked when i changed it to false, thanks @Isaac_Takushi any idea of what the downside will be having on false or for how long?

[#7]

Hey @Isaac_Takushi and @celston1n, I have implemented the forms v3 and im running into the same error on certain emails, see below for a few examples of emails:

kenkelly@yahoo.com
kellyken@yahoo.com
roydiligay@yahoo.com

[IsaacTakushi]

Hi @celston1n,

Yes. To my understanding, defining "skipvalidation": true will bypass all six checks I listed at the form submission stage. In this way, it would be like the v2 Forms API which let all those emails through.

[IsaacTakushi]

Hi again, @celston1n,

I've confirmed that the v2 endpoint itself doesn't use validation, but the CRM does validate before contacts are created.

The v3 endpoint, on the other hand, runs through the same checks as a regular HubSpot form if "skipValidation": false is included (as it is by default):

1. Formatting check: The text must look like an email address and the top level domain must appear in a public suffix list.
2. Domain blacklists: HubSpot maintains a list of throw-away email domains, like lasersharks.com.
3. DNS Lookup: The domain of the email address must have an MX record or an A record.
4. HubSpot Data Check: The email must not be globally blocked.
5. HubSpot Delivery Check: If HubSpot has ever delivered an email to the address, then the email is considered OK without continuing.

I'm unable to say exactly which check(s) the test emails failed, but you could bypass the v3 endpoint's validation by defining "skipvalidation": true. Certain emails might still be rejected before being created as contacts, however. To my knowledge, those checks are identical to the ones above.

[celston1n]

Thank you, @Isaac_Takushi. Am I right to assume that the "skipValidation" check would bypass all validations, not just the email one?

[IsaacTakushi]

Hi @celston1n,

Thanks for your patience as Tara and I work on this.

It seems the forms team added additional validation to the v3 Forms API beyond formatting that were not present in v2. I'm seeking insight as to exactly which checks are done before the form submits and before the contact record is created. Stay tuned for more details on this.

In the meantime, have you experimented with defining "skipValidation": true in your call? It's one of the optional parameters outlined in the documentation.

[IsaacTakushi]

Hi @celston1n,

I've run a few tests, but have yet to identify the issue with test20181002_1506@test.com. Here are some observations I have made, though:

• The test20181002_1506@test.com consistently passes the Forms API v2 validation, yet consistently fails v3.
• The similar address test20181002_1507@test.com consistently passes both.
• Other similar addresses, such as test20181002_1508@test.com and test20181002_1509@test.com also consistently pass v2, but fail v3.

Could you share similar addresses which have passed v3 validation? (Links to the contact records themselves would be even better.)

[celston1n]

Thanks for the feedback, Isaac. I don't have other email addresses to share that are failing. The ones in my examples were just ones I used to test the integration so I usually add date/time so I can tell which succeed and which fail. What I'm trying to determine is if there is a rhyme or reason as to why some fail and some succeed. If it's a remote edge-case, I can relay that to my client and we can proceed with our integration. If there are things we can test on our own, we can build that into the application.

Do you know and can you point me to an independent method to test an email's validity? I searched for one and could not find it so either it doesn't exist or just hard to find. If there is, we could validate in advance and do a more graceful fail back to the user or notify an administrator.

Given the inconsistencies in your results, are we still sure that the API is only validating the email address by syntax and not some other means?

Also, we're finding that the form submissions themselves are getting through but the point of failure is during the contact create step. I can share a screenshot through DM or other means as to not share leads' personal information.

[celston1n]

@Isaac_Takushi, any more detail you can provide would be helpful.