I’m hitting the same pattern several other developers have reported on this forum (threads 143028, 142690, 102257, 74014, 123600): a fresh Server-to-Server OAuth app’s event subscription URL validation fails with URL validation failed. Try again later. even though my endpoint is returning 200 OK with the correct HMAC-SHA256 encryptedToken response in ~60ms. This looks like the same server-side state issue Chun Siong has flagged before…I’ve exhausted everything controllable on my side and need an engineer to look at our app’s validation state.
App details
-
App type: Server-to-Server OAuth, Account-level,
Intend to publish: No -
App created today (May 12, 2026 UTC) on a Pro Named Host account
-
Webhook URL under test is on my own domain, behind Caddy + Cloudflare proxy, hitting an n8n workflow
What my endpoint returns
-
HTTP Status: 200
-
Content-Type:
application/json(stripped charset, Vary, Etag, CSP after first failure) -
Body:
{"plainToken":"<echoed>","encryptedToken":"<HMAC-SHA256(secret_token, plainToken) hex>"} -
Median response time: 60ms
-
HMAC implementation:
crypto.createHmac('sha256', secretToken).update(plainToken).digest('hex')– matches the reference code Chun Siong has posted in earlier threads
Verification
For one specific validation attempt your platform made to my endpoint today:
-
I captured the exact
plainTokenyour validator sent -
Computed
HMAC-SHA256(secret_token, plainToken)independently in Python’shmaclib -
Confirmed byte-for-byte match against what my n8n workflow returned
-
Confirmed 200 status code and ~53ms response time at the proxy layer
-
Marketplace UI still showed
URL validation failed. Try again later.for that exact request
Every Zoom Marketplace validation request (User-Agent Zoom Marketplace/1.0a) hitting my endpoint over the last 60 minutes has received a matching 200 + correct payload. Both reverse proxy access logs and n8n execution logs confirm this.
I can share X-Zm-Request-Id values + timestamps privately for the specific attempts you’d want to trace on your side.
What I’ve already tried
-
Stripped
Content-Security-Policy: sandboxfrom response headers (n8n’s default) -
Stripped
charset=utf-8from Content-Type so it’s a cleanapplication/json -
Stripped
Vary: Accept-EncodingandEtagheaders -
Changed the webhook URL path to a brand-new slug – fresh URL with no prior validation history – same rejection
-
Deleted the event subscription entirely and recreated it from scratch on the new URL – same rejection
-
Hard-refreshed the browser to clear any UI cache
-
Verified Zoom services are reported Operational on status page
Ask
Could someone please look at this app’s server-side validation state and either:
-
Tell me what your validator is actually rejecting (I’m out of variables to test client-side), OR
-
Reset whatever cached state is blocking validation so we can move forward
The endpoint is live and I can supply the app ID, account ID, request IDs, headers, or a specific timestamped attempt privately for diagnosis any time.
Thanks.
-Brett