# Does a Draft (Development) user-managed app receive webhook events at all? **URL:** \ **Category:** Zoom Events\ **Tags:** phone, webhooks\ **Created:** [July 31, 2026, 8:09am UTC](https://devforum.zoom.us/t/does-a-draft-development-user-managed-app-receive-webhook-events-at-all/145189 "2026-07-31T08:09:52Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![LOTHiroki](https://avatars.discourse-cdn.com/v4/letter/l/9d8465/32.png) [@LOTHiroki](https://devforum.zoom.us/u/LOTHiroki)\ **Post date:** [July 31, 2026, 8:09am UTC](https://devforum.zoom.us/t/does-a-draft-development-user-managed-app-receive-webhook-events-at-all/145189/1 "2026-07-31T08:09:52Z")
We have a user-managed OAuth app in Draft status (Activation state `--`, Zoom product: Phone). It does not receive any webhook events at all, and we would like to know whether that is expected for an app that has not been activated. Setup: - Event Subscription configured in the Development environment, using the Development Client ID, so the OAuth authorization and the subscription are in the same environment. - Endpoint is public HTTPS with a valid CA certificate, TLS 1.2+, accepts POST with JSON, and responds well within 3 seconds. - There is no Validate button for this endpoint, which we understand is expected for a development endpoint. We progressively widened the subscription to rule out event-specific causes. All of these saved successfully, and none were ever delivered: - `phone.recording_completed_for_access_member` and `phone.recording_transcript_completed` — outbound calls with recordings. - `phone.caller_ringing`, `phone.caller_connected`, `phone.caller_ended`, `phone.caller_call_log_completed` — several outbound calls. - `phone.recording_started`, `phone.recording_stopped`, `phone.recording_completed`, `phone.recording_failed` — same calls. The recordings were created and are visible in the portal. - `user.updated` and `user.settings_updated` — changed the profile at [zoom.us/profile](http://zoom.us/profile). The last one matters most: `user.updated` only needs `user:read:user`, which is granted, and it has nothing to do with Phone. It was not delivered either. The decisive observation is that our app’s webhook logs in the Marketplace are completely empty, with zero entries for all dates. The legacy webhook logs are empty too. The API call logs do contain entries, so the logging surface itself works. From Zoom’s side, no delivery has ever been attempted for this app. What we have ruled out: - The endpoint is reachable. Unsigned POST requests from the public internet return our own 401 and appear in our application logs. We ran such a probe immediately before and after every test window, so each negative result is backed by a demonstrated ability to detect an arrival. - Nothing arrives at all, accepted or rejected, across all instances in centralized logging. - Re-authorizing did not help. The original authorization predated the subscription by a month, so we re-authorized today and tested again. - The authorizing user is in the same account as the app, is a licensed Zoom Phone user, and can see the recordings. Questions: 1. Does an app in Draft Development status with Activation state `--` receive webhook events at all? We could not find documentation stating either way. 2. If it does, what makes an app eligible for delivery? Is there an install, activation, or local-test registration step beyond configuring the Event Subscription that we have missed? 3. Is there any way to see from Zoom’s side why no event is generated or routed to this app? Empty webhook logs give us nothing to work with. Happy to share the account number, client ID, call IDs and endpoint FQDN privately if that helps. ---
**Author:** ![LOTHiroki](https://avatars.discourse-cdn.com/v4/letter/l/9d8465/32.png) [@LOTHiroki](https://devforum.zoom.us/u/LOTHiroki)\ **Post date:** [August 3, 2026, 1:25am UTC](https://devforum.zoom.us/t/does-a-draft-development-user-managed-app-receive-webhook-events-at-all/145189/2 "2026-08-03T01:25:37Z")
Resolved, root cause was on our side Resolved. The premise of my original question was wrong, so I want to correct it here rather than leave it as a misleading data point for anyone who finds this thread later. **Short answer to my own question: yes, a Draft (Development) user-managed app does receive webhook events.** Zoom was sending them the entire time. The deliveries were being rejected at our own network edge before they ever reached our application, so from inside our app it looked identical to “Zoom never sent anything.” **Root cause (entirely on our side):** our webhook endpoint sits behind a WAF whose default rule is deny-all, with per-path allow rules added for each integration. The allow rule for our Zoom Phone path had never been added. The route existed and the backend was healthy — the traffic was simply denied at the edge with a 403 that our application never saw. **What misled me for four days:** 1. **My reachability test was invalid.** I verified the endpoint with `curl` from my workstation and got the expected 401 from the application, which I took as proof that the endpoint was reachable from the internet. But my machine was on a full-tunnel VPN, so every probe exited from our corporate egress IP — which matched a separate office/VPN allow rule. The probe proved only that the endpoint was reachable _from our office network_, not from Zoom. If your edge uses an allowlist, a successful curl from your own machine proves nothing about third-party reachability. 2. **The Marketplace webhook logs showed zero entries for all time** , which I read as “Zoom never attempted delivery.” Our load balancer logs later showed 28 delivery attempts from Zoom’s egress range (`170.114.0.0/16`) over seven days, every one of them denied at our edge. So an empty webhook log did not correspond to an absence of delivery attempts in our case. I’d be interested to know whether that is expected — if delivery attempts that fail at the network layer are simply not recorded there, that would be useful to document, because it removes the one signal a developer would naturally trust. Once the allow rule was added, the previously-blocked requests started passing and reaching the application immediately. **Two incidental findings that may help others:** - `endpoint.url_validation` challenges **do** carry the `x-zm-signature` and `x-zm-request-timestamp` headers. I could not find this stated in the docs, and I had only inferred it from the fact that validation is a signed challenge-response. It matters if you want to gate the endpoint at your edge on the presence of those headers. - Development endpoints have no Validate button (consistent with what Zoom staff have said elsewhere), but a Server-to-Server OAuth app does have one. That made the S2S app a useful cheap probe for endpoint reachability, independent of any question about the app under test. Thanks to anyone who read the original post. Closing this — the question as asked was based on a false premise, and the answer is that Draft user-managed apps do get events.