at Your New Topic as Follows: API Endpoint(s) and/or Zoom API Event(s)
Currently attempting to use the Zoom Phone API Assign Calling Plan(POST /phone/users/{userId}/calling_plans) endpoint
Description
I’m creating an onboarding automation for new users. I create a user with the SCIM2 New User Endpoint(/scim2/Users) which returns the newly created user (including the userID field)
I then attempt to use the CallingPlan API to assign a plan to the newly created user (using the provided userID from the creation response) but I get the error that the user does not exist. I’ve attempted using the “userName” field (since I know other endpoints accept the userName instead of userID sometimes) and I receive the same result.
Error?
{‘code’: 1001, ‘message’: ‘User does not exist: REDACTED@EMAIL.COM.’}
{‘code’: 1001, ‘message’: ‘User does not exist: REDACTED_USERID_FIELD’}
How To Reproduce Steps to reproduce the behavior: 1. Request
BODY* {“calling_plans”: [{“type”: plan_type, “billing_account_id”: account_id}]} 2. Authentication method or app type I’m using a Bearer Token authentication method with a Server-to-Server private app (from Zoom Market Place) to manage the required scopes
I’ve done some searching and most of the findings related to 1001 seem to be when the userID in question isn’t part of the JWT token’s account or some how not “in scope” however I think this must be different since I create the user in this case so it must be in scope
Hi @sh_dev
Thanks for reaching out to us!
Have you tried passing down the email of the user? Could you please share with me the request URL you send when you create your users so I can try and replicate this on my end?
Cheers,
Elisa
My process currently is to create a user via a POST to api.zoom.us/scim2/Users endpoint which then returns the user that was created
I then use the returned values and confirm that the user exists with a GET request to the same URI api.zoom/us/scim2/Users providing the returned “id” property to confirm that there is a user that was created. (the property looks like this in format >> 'id': 'AQbQWREDACTEDCZOjda-PA') which does return a single user matching the query so I’m pretty certain the user exists. I’ve also successfully confirmed that doing the same query with the “username” property (which is the user’s email testingUser@DOMAIN.com) worked too for the GET request and returned a the same user
Unfortunately, I’ve tried using the “username” property of the returned user (which is their email address in my case) and then I’ve also tried using the “id” property which is a string that appears to match the documentation’s example but return the 1001 error. Is this because the SCIM endpoint cannot create full users but rather stores them somewhere else?
If anyone else has suggestions I’d love help on this. I’ve still not been able to figure out in the grand scheme of things how I could assign a calling plan (with phone number from our pool) to a newly created user all through API
Hey @sh_dev
Sorry for the late response here!
Quick question, have you tried assigning the phone plan upon user creation?
You do have the option to do so using the SCIM endpoint
I have tried but maybe I’m not provided the correct info:
I tried using the below body to create a new account however, I cannot seem to get the account to be created as anything other than Zoom Meetings Basic when attempting to check the created account from User Management.
Maybe I’m reading the documentation incorrectly. I’ve tried using only “zoomPhoneCallingPlan” then only “zoomOneBizPlus” and then lastly together. The account seems to always be created as Zoom Meetings Basic
It’s possible I’m trying to assign the wrong plan type (and maybe if we don’t own the plan it defaults bac) However, I did a list_calling_plans API and it returned with 83200 so I think I’m correct:
{'type': 83200, 'name': 'Zoom Workplace Business Plus with US/CA Unlimited', 'subscribed': 285, 'assigned': 279, 'available': 6}]}
HEY so I think I might have figured out the issue, I was missing a base type for the user “licensed” to tell the API that there is licensing info included in the body otherwise it seems to ignore it.