Invalid access token - I can't get it to work

Hey,

I have a problem with the access token and can’t find the problem. Hopefully one of you can help me.
First of all, I am using the free account for testing.

I have created a new app in the Marketplace (Server to Server OAuth App) and entered all the relevant details.
The necessary entries are set under Scopes.
The app is activated in the account.

I generate my OAuth token using the following endpoint (account ID from the created app - checked and it is complete).
https://zoom.us/oauth/token?grant_type=account_credentials&account_id=OAPWRo5cQtiFZ9GMIV-86A

The Response I get back is the following:

{
    "access_token": "eyJzdi...4g",
    "token_type": "bearer",
    "expires_in": 3599,
    "scope": "user:read:list_users:admin clips:write:upload_file:admin",
    "api_url": "https://api.zoom.us"
}

I use the access token specified here to call up an endpoint that is shared in the app via Scope.
In this case /clips/files

So I perform a POST request to https://fileapi.zoom.us/v2/clips/files.
I have entered the following

Content-Type: multipart/form-data
Authorization: "Bearer " + msg.resp_auth.access_token (references the previously generated access token - is transferred correctly)

the body contains:

{
  "file": "@\\\\DiskStation_923\\Automation\\Zoom\\komodo-unlimited-screen-recording-and-sharing.mp4"
}

As a Response I then get back:

resp: Object
code: 124
message: "Invalid access token."

Where is my error?
Why do I get “Invalid access token” as a response? I have tried the GET /users endpoint - it returns data as expected.

I’ve already invested some time in it, but unfortunately I can’t find the problem.
Would be great if someone could tell me exactly where the error exactly is.

Thanks already in advance.

Kind regards,
Ben

P.S.: I removed all “https://” from the requests and responses because it won’t let me create this topic otherwise. In my requests

How does your calling code handle redirects? I noticed these disclosures in the Upload clip file (POST /clips/files) documentation:

  • The caller must support HTTP 30x redirects.
  • The caller must retain the Authorization header when redirected to a different hostname.

I haven’t used this API endpoint, so I’m wondering if Zoom sends an HTTP 302 or 307 status code. Most clients will treat status code 302 as a signal to change the redirected request to a GET method (like a typical form submission and original page refresh workflow), which discards the request body, so you might need special handling to make sure that the redirected request still contains your authorization header and request body, which is what status code 307 explicitly implies.

The request body in your example doesn’t seem to be formatted as multipart/form-data; I was expecting to see MIME boundaries, not JSON. Maybe your framework is interpreting it as instructions to produce the actual request body?

Hey Christopher,
Thank you very much for your feedback.

the MIME boundaries are generated automatically by my tool.
I’m actually not sure about the HTTP30x redirects.

I have tested the whole process via Postman (using the material provided by Zoom).
I get back a 200 status with an empty body.
Even with activated settings:

  • Automatically follow redirects
  • Follow original HTTP Method
  • Follow Authorization header

To be honest, I’m at my wit’s end.
Do you have any other idea what the problem could be?

I’d get an HTTP debugger / analyzer and have it capture the traffic sent from your application. Typically this is done by having it act as a proxy server (it’ll tell you the address and port), and instructing your application to use that proxy server before sending any requests. Then you can capture the raw request and raw response and compare that to what you see in Postman.

A decade ago (in the 2010s), Windows developers tended to use Fiddler for this purpose; I’m not sure if it’s still trendy or suitable for your environment.

I’m still worried about the lack of certainty around redirect behavior, since there’s a clear path that explains how that would cause customizations to be dropped during the redirect. Redirections are particularly weird / wasteful to be used in API calls, so there’s a good chance that surprising behavior is happening.

Hey @MultiplayerSession Thanks for chiming in here!
@BenH I am taking a look at this and trying to replicate on my end. I will get back to you with my findings

Hey! @BenH
I am not able to replicate on my end, I was able to upload a clip using the following curl command:

curl -i --location --request POST 'https://fileapi.zoom.us/v2/clips/files' \
--header 'Authorization: Bearer {your access token}' \
--form 'file=@/Users/ElisaL/Desktop/clip04.mp4'

I am happy to troubleshoot this further for you! Let me know and I can send you a DM for more details