Potential bug: recurring bookings may reuse the same videoCallUrl across all occurrences

[amineneff]

Issue Summary

Recurring bookings can end up reusing the same videoCallUrl for every occurrence instead of generating or storing a unique meeting URL per booking. This is a user-facing bug because later meetings in the series may point to the first occurrence’s link, which can be stale or expired by the time the future meeting happens.

Steps to Reproduce

1.Create a recurring booking with a video integration enabled, especially Cal Video.
2.Confirm the recurring booking.
3.Inspect the created bookings, webhook payloads, or calendar event metadata for each occurrence.
4.Compare the videoCallUrl across multiple occurrences in the series.

Any other relevant information: the recurring booking flow appears to compute a single meeting URL and reuse it for all occurrences, rather than deriving a URL per booking instance.

Actual Results

. All recurring bookings can share the same videoCallUrl.
.Future occurrences may point to the first meeting’s link.
.If the first link expires, later meetings can break.

Expected Results

1/Each recurring occurrence should have the correct video call URL for that specific meeting, or
2/The system should intentionally store a recurring-safe URL strategy that remains valid for all future occurrences.

Technical details

1.This appears in the recurring booking confirmation flow in 2.packages/features/bookings/lib/handleConfirmation.ts (lines 257-292) and again in webhook payload 3.generation in the same file.
4.Existing tests already flag this with FIXME in [apps/web/pages/api/book/recurring-event.test.ts](cal.com/apps/web/pages/api/book/recurring-event.test.ts:205, 554, 772).
5.No browser-specific issue. This is backend/booking-flow behavior.
6.Node.js version was not verified for this report.

Evidence

1.Code inspection shows a single meetingUrl is computed and then reused for the entire recurring confirmation 2.batch in packages/features/bookings/lib/handleConfirmation.ts (lines 257-292).
3.The same value is also used in webhook payloads in packages/features/bookings/lib/handleConfirmation.ts (lines 580-590).
4.The recurring booking tests explicitly note the bug with FIXME comments in [apps/web/pages/api/book/recurring-event.test.ts]
(cal.com/apps/web/pages/api/book/recurring-event.test.ts:205, 554, 772).

[rnagulapalle]

This looks valid, and the repo already seems to know about it.

The important detail is that handleConfirmation.ts computes a single meetingUrl once up front, before the recurring booking loop, and then reuses that same value when updating every recurring booking’s metadata. The webhook payload path also appears to reuse that same URL afterward.

So the bug is less “webhooks are wrong” and more “the recurring confirmation flow currently treats the meeting URL as batch-level state instead of occurrence-level state.”

That lines up with the existing recurring tests too — there are already FIXME notes saying recurring bookings seem to share the same URL, with the warning that future meetings could end up using an expired first-occurrence link.

If Cal Video / the provider intends one stable URL for the entire series, that should be explicit and documented. But if the intended model is one URL per occurrence, then the fix probably has to happen before webhook generation:

• derive/store the video URL per created booking instance
• then build webhook payloads from per-booking metadata instead of the shared meetingUrl captured outside the loop

So I think the issue framing is right: this is a recurring confirmation flow bug first, with webhook payloads just inheriting the wrong state.