Stopped receiving webhook notifications on Friday June 25 (Reverse Proxy)

A Webhook Only app has stopped working after Friday, June 25, 22:06 GMT. The Webhook logs in the Marketplace show a Status 500.
Our notification endpoint URL is behind a Fortigate Web Application Firewall appliance, acting as a reverse proxy.
When we redirected the webhook to hit the backend server directly (with a different FQDN), the events were being received normally, with a Status of 200.
Both the backend server and the Fortigate WAF appliance have been properly configured with the same SSL certificate. This setup was working for more than a year until Friday, but never worked after that time.
The logs of the Fortigate WAF appliance, just show a Connection Reset event, and nothing else. The Webhook notifications never reach the backend server, there is no trace of them in the HTTP server logs.
We tried to reproduce the problem using Postman, but we were unable to see the same behaviour. A simulated Zoom Webhook notification sent from Postman to the server, through the WAF appliance, is received properly.

I don’t want to include the actual URLs and FQDNs here, for security reasons. If needed, I can provide them on a private communication channel.
The app can be found at:

The Webhook logs (Status 500) in the Marketplace show this error for every event notification sent to the server through the Fortigate WAF appliance:
“responseHeaders”: false,
“responseData”: “Connection closed”,
“runTime”: “637”,
“ttl”: 1626182443,
“requestParameters”: undefined

Which App Type (OAuth / Chatbot / JWT / Webhook)?
Webhook Only

How To Reproduce (If applicable)
Steps to reproduce the behavior:

  1. Set the notification endpoint URL to reach our server through the WAF appliance
  2. No Webhooks are received, all logs show Status 500 with the above error
  3. Set the notification endpoint URL to reach our server directly
  4. All webhooks are received, logs show Status 200

Additional context
The only events that we have configured the application to send are meeting.participant_joined and meeting.participant_left.
We do suspect that this is an SSL protocol negotiation issue, but we will need input from Zoom to debug it.

Hi @apochr,

Thank you for reaching out about this.

If you were able to receive events when providing the URL for your direct server, and are able to test successfully in Postman, I agree this sounds like an environment issue.

I’m happy to see if there is any additional information we might be able to provide you from our logs. Can share the full details of the URL you were using (that results in the 500 error you’re seeing in the logs) with us directly at This will help us to take a closer look.


Just sent the info to the developer support mail, Will. Thanks for your help.


Thank you @apochr,

We will be in touch shortly!


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