Other people have discussed this in the past, where subscribing to webhook-only events and triggering them causes a connection to be received from Zoom and a HTTP POST request sent, but the JSON POST body is missing. Here’s another one.
Webhooks receive HTTPS connections and headers, but no POST body.
We are logging requests very in-the-raw, collecting all possible data off the network connection before exiting any given instance. Here’s what I see in the log at the endpoint:
and then nothing, even after the connection exits. We expect the JSON body right above the second “===” I’ve delimited the output with. We respond (blindly) with a 200 either way, no parsing is done at this point. In the meantime, the app log up at the Marketplace site does show the JSON body that would have been delivered, with no particular errors noted in the process.
Which App Type (OAuth / Chatbot / JWT / Webhook)?
webhook [v2, I think]
Please ask privately if you need that. You can probably dig that out of the headers and look up our account. (business tier at the moment)
How To Reproduce (If applicable)
Steps to reproduce the behavior:
Run the listener / collector-script
Start a meeting, or do any other subscribed event
Why is a one-shot webhook delivery process trying to set “Connection: keep-alive” ?? This isn’t how webhooks are supposed to work. We expect a new connection for every event.
Thank you for posting, and I’m sorry about the Webhook JSON discrepancy. That behavior sounds strange. To make sure I understand correctly, the Marketplace log does show the JSON body that would have been delivered. However, your endpoint is only receiving some of the payloads. Is that correct? Typically, if the JSON body is logged in the Marketplace, you should also see the same at your endpoint. Can you share the events you’ve subscribed to and if the behavior is reproducible?
I eventually did figure this out, and mailed in about it. The JSON body is sent without a trailing newline. An endpoint that is expecting record-oriented network input, which is likely true for several language one might wind up using, may easily miss the fact that there was an extra record during network reads because it never “completed” in that language’s view.
There would be no harm in Zoom adding another newline, either a bare LF or a CR-LF pair, to the webhook payload, and that might make it easier for some developers to parse the stream. Once we started looking for “}” as a record separator instead, the bulk of the payload showed up – in kind of weird chunks, but this was a very raw experiment so it worked well enough.
Thank you for having taken the time to provide us with your valuable feedback @hobbit! I’m sorry to hear about any frustration you may have experienced with the JSON body. If you have not already done so, we welcome you to submit your feedback for consideration here: Feedback - Zoom
Thank you again! We’re looking forward to making your experience even better in the future!