When requesting recordings from a user account, I get an “Invalid access token, does not contain scopes: [recording:write:admin, recording:read:admin]” Error. Even though that request in the documentation says it can take the recording:read scope too. I just want access to the recordings the specific user has access to. I would rather not require account level admin scope if possible.
The user requesting the recordings is the account owner, but I would expect it to behave the same way for any user on the account. The auth token does have valid recording:read recording:write scope
Ok…so I was testing a theory about the /me variable you guys use sometimes. Apparently that allows this to work without the admin scope. Interesting that the userid doesn’t work, even though “me” and the userid were the same user. So my issue is resolved for this, since I can just use “me”, but you should update your documentation or fix the /users/{userid}/recordings API so it actually works when requesting recordings and using the userid that matches the authorization token.
Our documentation states you need the user:read:admin and user:read scopes, when you actually need the recording:read, and recording:read:admin scopes.
The userID and email do not work for the userID when using a User-Level OAuth app to List All Recordings. Only the me context works.
Thanks for sharing this, we will work on a fix.
-Tommy
Yes, you summarized perfectly @tommy, thanks for following up. I didn’t even realize how far off the scopes where in the docs, glad you are on top of it. Now if the other problem of the 403 error on recording downloads gets fixed, I can actually test all of this
Update, this is the intended functionality. We will update our docs to make this more clear.
User-level OAuth apps with the recording:read scope can only call the GET /users/{userId}/recordings by passing in me as the {userId}. Email or userId will not work.
Thanks Tommy. Might want to put that up front in the docs, not just for this endpoint, that /me/ is not synonymous with your /{userid}/. I expected they would resolve to the same thing as they are the same user.
