Event Subscription webhook (meeting.participant_joined) never delivered in Development mode - even after fixing TLS chain, still zero delivery attempts

API and Webhooks
,
1

We’re trying to receive the meeting.participant_joined webhook for a Development-mode, admin-managed General (OAuth) app. OAuth admin consent completed successfully (confirmed via a GET /users/me call returning our account_id), and the Event Subscription is configured and saved without any error in the console. Despite this, Zoom never calls our endpoint - not even the initial endpoint.url_validation handshake.

While investigating we found and fixed a real bug on our side: our endpoint’s TLS certificate chain was missing the intermediate CA certificate, so strict TLS clients (verified with openssl s_client) failed the handshake with “unable to verify the first certificate” (verify code 21), even though browsers and curl worked fine due to AIA-chasing. We fixed this, confirmed Verify return code: 0 and confirmed the endpoint is reachable from an external network with a normal HTTP response. We were hoping this was the root cause of Zoom’s silent delivery failure. However, even after the fix, we still get zero delivery attempts from Zoom’s side - no retry of endpoint.url_validation, nothing, even over several hours and multiple test joins.

We already filed a ticket with Zoom Support and were directed here.

2

Error?

No error is shown anywhere in our stack - our reverse proxy’s raw access log shows zero inbound connections from Zoom’s infrastructure at any point, only our own manual test requests. No error is shown in the Zoom Marketplace console either; the Event Subscription just saves normally with no validation failure message.

How To Reproduce

Steps to reproduce the behavior:

  1. Request URL / Headers / Body: N/A from our side - the issue is that no request is ever received. Our endpoint is a standard HTTPS POST receiver expecting Zoom’s webhook payload with our app’s Secret Token in the request headers, per the docs.
    1. Authentication method or app type: General App (Admin-managed, OAuth), Development mode. Scopes granted: meeting:read:participant:admin, user:read:user:admin. App is installed for Local Test.
      1. Any errors: None surfaced anywhere - just silent non-delivery. Reproduced consistently across multiple attempts:
        • Configured Event Subscription (Webhook method) for meeting.participant_joined, endpoint URL saved
          • Deleted and fully recreated the Event Subscription from scratch - still nothing
            • Tried both All users in your account and Only for users who have added this app for notification receiver - no difference
              • Joined a live meeting under the connected account multiple times, same login that completed OAuth consent, with a distinct participant display name, confirmed via the Zoom clients own Participants panel that the join succeeded each time - no webhook ever received
                • Also tested ending the meeting in case the event was batched/delayed post-meeting, and waited several hours afterward - still nothing
              • Is there an account-level install step for Development-mode General Apps beyond per-user OAuth consent that we might be missing? Any pointers appreciated.
3

Any guidance folks? :slight_smile:

4

Update - tried both suggested workarounds, same result

Went back into the Development app console specifically looking for a manual “Validate” step before Save, since some docs describe that flow. In our case there isn’t one - the event subscription editor only has Save/Cancel, no CRC-trigger control at all, and clicking Save produces no error, no spinner, and no confirmation beyond the form collapsing back to its summary view.

To rule out the Marketplace UI itself as the culprit, we also created a second, independent event subscription for the same event via the API (POST …/event_subscription, subscription_scope: “account”, no account_id needed - it’s inferred from the client-credentials token). That returned 201 Created, not a validation-failure error, so on paper Zoom accepted it.

We then ran a live test: joined a real meeting under the connected account twice, once as a plain participant and once using a display name matching a common third-party meeting-notetaker naming convention, confirmed both joins in the meeting’s own Participants panel, and watched our reverse proxy’s raw access logs live the entire time.

Result: zero inbound requests from Zoom for either join, on either subscription (the original UI-managed one or the new API-created one). No CRC call, no event delivery, not even a malformed request - literally nothing.

At this point we’ve ruled out: TLS/cert chain (fixed and verified earlier in this thread), UI-managed vs. API-created subscription (both silent), scopes (correct scope granted, confirmed via a successful GET /users/me), and host identity (the joining participant and the OAuth-consenting user are the same account). We’re out of ideas for what else to check on our end - would really appreciate any pointers, or if a staff member could take a look at provisioning state for this app’s Development event subscriptions.

5

Update - verified the PATCH “subscribe” step, and checked Zoom’s own Webhook Logs

Good catch from someone reviewing this off-forum: the event_subscription POST alone only creates the subscription definition - it doesn’t actually subscribe the account until you PATCH /marketplace/app/event_subscription/{id} with account_id (returns 204). I hadn’t done that step for the API-created subscription, so my earlier “API-created subscription was silent too” claim wasn’t fully conclusive on its own.

Went back and did a GET on all our event subscriptions and found something useful: our original, UI-created subscription already had a populated subscriber_id (plus correct subscription_scope, event_webhook_url, and events list) - meaning it was genuinely, verifiably live and subscribed the entire time, including during every live-meeting test we’ve run in this thread. So that earlier zero-delivery result already stands as solid evidence against a fully-provisioned subscription, no PATCH needed for that one.

For the separate one I’d created via the API, I then ran the PATCH, got 204, and confirmed via a follow-up GET that it now also has a proper subscriber_id. Haven’t re-run a live join specifically against that freshly-patched subscription yet, so I’m not claiming that one as additional independent evidence - just noting it’s now correctly provisioned too, for anyone following along.

Separately, I checked Marketplace > API call logs > “Legacy Webhook Logs” for the account (Time/Date, Status, Endpoint columns, most recent 100 calls / last 7 days). It shows “No data” - not a failed delivery, not a retry exhausted, literally zero delivery attempts logged by Zoom’s own dashboard, despite our live join tests happening well within that window against a confirmed-subscribed subscription.

So at this point: TLS confirmed fixed, at least one subscription confirmed correctly provisioned end-to-end (verified subscriber_id, not just “saved”) during every live test we’ve run, real qualifying events occurred, and Zoom’s own webhook log shows zero delivery attempts - not just our side seeing nothing. That rules out our endpoint/network path as the cause pretty conclusively. Would appreciate a staff look at whether events are even being generated/routed for this account’s Development-mode subscriptions.

7

Hi @Abbyris , seems like you have done quite a bit of troubleshooting and fixed a few things on your end! Could you please tell me if you can reproduce this behavior with the sample app? GitHub - zoom/webhook-sample: Receive Zoom webhooks. · GitHub