Hi Botpress Support Team, @cold-motherboard-82208 @ Objective: I'm trying to get the Calendly "Event Scheduled" webhook trigger working reliably in my Botpress chatbot so that booking confirmations fire correctly for all meeting location types, ahead of a production deployment. Issue: The "Event Scheduled" trigger fails specifically for Calendly bookings that use Zoom as the meeting location. The integration throws Invalid webhook payload structure and the event never reaches the bot. Bookings using phone call as the location work correctly with no errors — the failure only happens with Zoom. Solutions already attempted: Verified the issue is consistent and reproducible: every Zoom-location booking fails, every phone-call booking succeeds. Reviewed the integration's public source code and traced the root cause to integrations/calendly/src/webhooks/schemas/locations.ts, where the Zoom location schema checks for type: 'zoom', but Calendly's actual payloads send type: 'zoom_conference' (consistent with the other location types like google_conference and webex_conference). Since the location schema is a union, this mismatch causes the entire payload validation to fail. Forked the repo and prepared a one-line fix, but couldn't open a PR since pull requests are restricted to collaborators. Filed a detailed bug report with the root cause and fix here: [botpress/botpress#15386](https://github.com/botpress/botpress/issues/15386) Context: Integration: Calendly (@botpresshub/calendly, v0.0.6) Trigger: Event Scheduled Location types tested: Zoom (fails), Phone call (works) Impact: This is currently blocking a production deployment for my project. Screenshot of the error log attached for reference. I'd really appreciate a prioritized fix here, given the deployment timeline — happy to share any further logs or details that help. Thanks so much for the support! https://cdn.discordapp.com/attachments/1531973669260099614/1531973669935513692/image.png?ex=6a6b2929&is=6a69d7a9&hm=1b8a5503e633e3c5eae56befaaf9ddaf6787168ecbc1fa16fa49465bb12492b6&

Hello Have you been able to sort this Or you still need some help

Hello @polite-camera-79519 , Unfortunately, I don't have the necessary permissions to modify the source code in GitHub or create and publish a refork. I've already documented the issue in detail on the GitHub issue page: https://github.com/botpress/botpress/issues/15386, including the changes that need to be made. If you have the required permissions, could you please review the issue, implement the necessary code changes, and publish an updated fork? That would be greatly appreciated.

Thanks for the report, the symptom, the location-type A/B, and the repro all held up exactly as written, and you pointed us at the right file. The bug is confirmed, but the discriminator isn't what's breaking it. Calendly sends location.type: "zoom", so the existing z.literal('zoom') matches — we verified this from the raw union error on real failing bookings, where every non-Zoom member reports "received": "zoom". zoomConferenceSchema is the member that passes the type check, then fails on two fields inside data: - data.id is typed z.string(), but Zoom meeting IDs arrive as a number - data.extra.intl_numbers_url is .optional(), but Calendly sends it as null (.optional() allows absent, not null) Either failure collapses the union, and since location is required the whole payload is rejected and the event dropped. This is also why your phone-call case passed — those schemas have no data object, so neither field is reached. So we won't merge the 'zoom' → 'zoom_conference' swap as-is: it leaves the two data fields broken, and replacing the literal would break the spelling we have live payloads for. Your point about the naming inconsistency is still worth covering, so we're accepting both: type: z.enum(['zoom', 'zoom_conference']), id: z.union([z.string(), z.number()]).optional(), intl_numbers_url: z.string().url().nullish(), Next steps: the engineering team is aware of the issue and will be in charge of fixing it. You'll need to update the integration on your bot once it's published, it won't apply to your installed version automatically. We'll comment here when it ships so you can verify against your own bookings. If you can share your workspace or bot ID, we'll validate against your specific payloads before shipping. And if yours do send zoom_conference, that payload would be useful to see, but the z.enum covers it either way.