Code change , why?

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

I’ve been running a video editor for my users for the last 3 months or so. Was code complete. Somewhere last week something changed that broke my site/app.

This is the code I was running in PHP :

function get_access_token_and_user_id($oauth_token,$website_redirect,$Client_id,$Client_secret,&$user_id,&$access_token){
$url = ‘’ . $oauth_token . ‘&redirect_uri=’ . $website_redirect;
$options = array(
‘http’ => array(
‘header’ => "Authorization: Basic " . base64_encode($Client_id . “:” . $Client_secret),
‘method’ => ‘POST’
$context = stream_context_create($options);
$result = file_get_contents($url, false, $context);
if ($result === FALSE) {
return false;
$data = json_decode($result);
$access_token = $data->access_token;
$str_exploded = explode(’.’,$access_token);
$final = json_decode(base64_decode($str_exploded[1]));
$user_id = $final->uid; // NOW THIS IS CORRECT
// $user_id = $final->userId; // THIS USED TO BE CORRECT
return true;

Why did you guys change this ? Seems an unrequired change that only breaks code without actually adding anything…

This is what $final now looks like :

object(stdClass)#2 (14) {
[“ver”]=> int(7)
[“auid”]=> string(32) “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”
[“code”]=> string(33) “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”
[“iss”]=> string(29) “zm:cid:xxxxxxxxxxxxxxxxxxxx”
[“gno”]=> int(0)
[“type”]=> int(0)
[“tid”]=> int(0)
[“aud”]=> string(21) “
[“uid”]=> string(22) "xxxxxxxxxxxxxxxxxxxxxxxx"
[“nbf”]=> int(1595440646)
[“exp”]=> int(1595444246)
[“iat”]=> int(1595440646)
[“aid”]=> string(22) “xxxxxxxxxxxxxxxxxxxxxx”
[“jti”]=> string(36) “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx” }


Hey @a.sinnige,

Not sure what you are trying to do. Are you trying to JWT Decode the access token? If so, doing so is not documented or supported, hence, could change anytime.

To get the userID of a user, use the Get User API.


I was using your own advice :slight_smile:

No worries about it… I like keeping the amount of calls as few as possible.
Why make more calls if you already have the information ?

It just seems like a change that to me served no purpose…


This has broken my integration also. I’m surprised it’s been 6 days and only one other person is complaining.

Tommy, this is a breaking change, of normal behaviour.

Example behaviour:

  • User signs up for app on marketplace
  • User accepts permissions
  • User is redirected to 3rd party website with a “code” URL param
  • 3rd party website makes a call to to confirm the “code”
  • Zoom responds with accessToken and refreshToken JWTs
  • 3rd party stores the JWTs for later use. The accessToken JWT includes “userId” which is equivalent to the “host_id” returned by many Zoom API calls. “userId” is stored as an individual database field for easy lookup

And then: Zoom cloud recording webhook:

  • 3rd party app receives a webhook call from Zoom
  • Webhook receiver code receives a JSON payload which includes payload.object.host_id
  • Search database for user with host_id == payload.object.host_id
  • Download the cloud recording and connect it to that user

None of this can happen anymore, because the accessToken no longer contains a field “userId”. It has been renamed to “uid”.
I now have to put yet another workaround in my Zoom code: check for tokenDecoded.uid || tokenDecoded.userId

Get used to these changes from Zoom, they do it frequently without previous alerts to developers.

1 Like

Hey @Emanuel_Aguirre, @a.sinnige, @james2,

JWT Decoding the access token is not something listed on our docs, hence it could change anytime.

Apologies for the inconvenience and for suggesting this in the past.

To get the userID of a user, use the Get User API. The me context is also helpful when getting information about the user of the access token.


Hi Tommy,

I still respectfully disagree. It’s common practice to decode JWTs at either end and make use of that data. Any time an API changes an attribute name it is a breaking change.

Just because it’s “not listed in your docs” doesn’t mean that you can break common convention relating to it. I run a web app and none of my docs say “you can use a mouse to interact with this web app”, but I’m still not going to break mouse functionality one day for no reason.


Yep Emanuel, this is either the 4th or 5th breaking change I’ve had to deal with in the last couple of years of using Zoom APIs in production sites :frowning:

Thanks for your feedback @james2.