Create meeting fails with HTTP 200 status and no response

I’m trying to create a meeting using a JWT token. I can retrieve a list of existing meetings fine, but when calling POST with the following body, no meeting is created, and the response is blank (HTTP 200 status, instead of the expected 201):

  "topic": "This is a test meeting",
  "type": 2,
  "start_time": "2022-01-12T10:00:00Z",
  "duration": 60,
  "password": "12345678"

I’m doing this in Postman with a free Zoom account.

Blank response, with HTTP 200 status. Which is very confusing since this is a success code.

Which App Type (OAuth / Chatbot / JWT / Webhook)?
Using a JWT token. Have confirmed that this works fine when retrieving a list of meetings.

Which Endpoint/s?
Using the POST /v2/users/me/meetings endpoint.

Thanks for any help you can provide!

For the endpoint address, which user ID are you specifying in place of “me”? JWT applications run at the account level (and can carry out activities on behalf of any user that belongs to that account), and this is a user-level API, so you will need to indicate specifically which user should receive the meeting.

You can fetch user IDs with the List users API.

Ah, OK, that’s a good point, and good to know. I’d initially been using a specific user ID (obtained from the list users API response), and assigning it to the schedule_for property too, before changing it to “me”. I’ve switched back to that, but both have the same result - a 200 response with no body, and no meeting created. Any other thoughts you might have would be appreciated!

Okay, it was worth a try. I see another person is facing similar symptoms; perhaps you can join in: Create meeting API returning blank response with 200 ok - API and Webhooks - Zoom Developer Forum

The API Call Logs for my JWT application show an HTTP 201 status code with a body of {"topic":"Sample Meeting","type":1}:

"endpoint":  "[redacted]/meetings",
"response_headers": [
 "Set-Cookie: zm_aid="";; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; Secure; HttpOnly"
"date_time":  "2022-01-12 13:12:20",
"method":  "POST",
"request_body":  "{"topic":"Sample Meeting","type":1}",
"response":  "{"uuid":"[redacted]","id":[redacted],"host_id":"[redacted]","host_email":"[redacted]","topic":"Sample Meeting","type":1,"status":"waiting","timezone":"America/New_York","created_at":"2022-01-12T18:12:20Z",[...]",
"request_headers": [
 "authorization: ******",
 "connection: close",
 "content-type: application/json; charset=utf-8"
"request_params": [
"http_status":  "201"

Interesting. Do you have a paid Zoom account? I’m wondering if that could be the difference. Interestingly, these calls don’t appear in my API call logs, though others do. Thanks for pointing out that other thread - I’ll respond there too. Thanks for your input!

Our account does have licensed users, but I’ve also called this meeting API on behalf of Basic users. That said, this does feel like a service problem (maybe the upstream server closed the connection and the proxy server substituted a blank response), so I’d try to get the direct attention of support.

I’ve sent an email to support and will see if they respond there. If so, I’ll put the answer back here to help others if they have the same issue. Thanks for your help!

1 Like

Hi @christhecoder

Thanks for reaching out to the Zoom Developer Forum! I have already replied to you and will update you shortly on this matter.


If anyone else has this same issue, the issue was that there was an incorrect header included in the request. When importing the Zoom collection into Postman, many of the requests are formatted as form data, but the API doesn’t appear to actually support this format. I had changed it to a JSON request, but the Content-Type header from the imported Postman file remained (Content-Type=multipart/form-data), and the mismatch of the content type header to the actual content type led to this issue. By removing this header from the request, the call started to work as expected.

Ideally all the requests in the Zoom Postman collection would be formatted as JSON requests, which would help avoid this issue, and also make the collection more usable for devs to get up and running. In addition, the 200 (success) response I received added additional confusion.

Thanks Elisa for your help in identifying this issue.


Hey @christhecoder

Thanks for posting and update for the community here!!! This is very thoughtful and I appreciate it!

Happy to have worked with you!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.