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.
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:
Does an app in Draft Development status with Activation state -- receive webhook events at all? We could not find documentation stating either way.
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?
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.
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:
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.
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.