Validation rules for email format when creating new user

Description
Details validation rules for email format when creating new user through the API

Error
Invalid fields for “user_info.email”

{
  "code": 300,
  "errors": [
    {
      "field": "user_info.email",
      "message": "Invalid field."
    }
  ],
  "message": "Validation Failed."
}

Which App Type (OAuth / Chatbot / JWT / Webhook)?
JWT

Which Endpoint/s?
POST /users

How To Reproduce (If applicable)
Steps to reproduce the behavior:

  1. Create new user with the information below:

    {
       "action": "custCreate",
       "user_info": {
         "email": "DLcL2-66o0m9GwJCXcdHOA2@abc.c3CzdyWTXUKvay-ys-Rgcg2.a--KtroyIki-x5Y2tNxZTw2.abc.com",
         "type": 2,
         "first_name": "TestFirstName",
         "last_name": "TestLastName"
       }
    }
    
  2. See error

Additional context
Previously, I can create user with a not-well-formed email address using the API. However, recently, this does not work anymore as I am getting the validation error like above. The documentation only mentions that email field cannot be exceed 128 characters and nothing else, so that email above should work no mater what if the email is not followed the format specs from RFC. The reason that I choose that kind of email format is just to create unique users and these users do not need to know the account in order to creating events in Zoom as they would have to go through my application. So I would like to know what kinds of rule that are being validated when creating new users and those rule needed to be documented so the API developers can devise correct solutions when running into issue like this.

Hey @Thai_Nguyen,

We are strict on the validation of emails.

Have you tried creating users via the +string@ trick? This tactic will work with our validation.

See #1 here:

Thanks,
Tommy

Thanks for the quick answer. It appeared to be working for me. Previously I was looking at that but at that time, Zoom was not letting me to use that kinds of format for email so that was the reason I had to derived a different format.

1 Like

Happy to help @Thai_Nguyen! :slight_smile:

If it was working prior, we may have made the email validation more strict. Yeah I would go with the + trick from now on.

Thanks,
Tommy