From response schema of /users API, I got to know that extension field would represent “PBX extension number” and phone represents “phone number”. Since I only see space to add mobile number for users in sandbox account , I used PUT to update single user to have phone and extension . (attached screenshot) . In real world scenario, is it possible to create a user without phone , mobile or extension or better to ask Is if-- Name, First Name, Last Name and Email – are only required fields ?
Hi @Aakash! You have this habit of asking questions about articles that I’m in the process of writing . There should be a Tutorial in the Guides & Resources section of the Developer Portal in the next week or so that walks through creating users, groups, and sites.
The /users route is a bit odd, you can only create users with the role of USER and other fields are locked down. Best practice is to use the /accounts/{accountId}/users route instead.
The only mandatory field is the email address, the rest are entirely optional or will be automatically populated on successful creation (userId, uniqueUserId, role defaults to USER, etc).
There’s no reason why you can’t use the Admin API to create Users, especially if you’re building an integration to share user info. That said, there are two other ways that Users get created which are often the ‘better’ option if you just simply need to create a User:
If you have a PBX configured and connected to CloudLink through a supported CloudLink Gateway, create the user on the PBX and they will be automatically synced.
Thank you for quick response and updating me with the information Actually I only updated existing user using /users but I was able to create new ones using /accounts/{accountId}/users route as suggested. I also tried other suggested way of creating a user using the Mitel Accounts portal and observed, It is possible to create a user just with emailId field using the API but sandbox/ UI doesn’t allow the same, it does requires Name, FirstName and Last name in addition to emaiId to create a user .
The /users route does work for a bunch of stuff, in particular updating an existing user provided you aren’t trying to change their role. There are some limitations to it though that are in place for super secret reasons (no one remembers). The Accounts portal UX has data validation in the form for various fields, so that’s what’s enforcing the requirement for the name fields…but the API is less picky.