Add "reschedule requested" webhook + associated toggle in event type settings

[still-orogenic]

Is your proposal related to a problem?

PR #18773 has introduced a problem for my workflow. I have bookings set up to require confirmation; the "Booking requested" webhook activates a Make.com scenario that checks my CRM for whether the booking meets certain criteria per client, e.g., the requested booking occurs at least N number of days after the client's previous booking of the same type.

Before PR #18773 , a reschedule would require confirmation, which would activate the same Make.com scenario with my custom logic. Now, reschedules are automatically approved on the Cal.com side, bypassing my Make.com scenario.

Describe the solution you'd like

I agree that the current behavior makes sense for most uses cases and should remain the default. However, I'd also like to have a "Reschedule requested" webhook, which I could then explicitly link to a Make.com scenario.

This could be paired with a clarified set of options in the Advanced tab for an event type on Cal.com:

Requires confirmation

• Always
• Only when initially booked
• Only when rescheduled
• When booked with less than 30 mins notice
• When rescheduled with less than 30 mins notice
• Unconfirmed bookings still block calendar slots.
• Only require confirmation for free email providers (Ex. @gmail.com, @outlook.com)

Describe alternatives you've considered

This seems like the most straightforward solution to me. Cal.com could extend an event type's limits to include per-client limits, but I think that would introduce needless complexity.

Additional context

None.

Requirement/Document

Not sure.

---

House rules

• If this issue has a 🚨 needs approval label, don't start coding yet. Wait until a core member approves feature request by removing this label, then you can start coding.
  • For clarity: Non-core member issues automatically get the 🚨 needs approval label.
  • Your feature ideas are invaluable to us! However, they undergo review to ensure alignment with the product's direction.
  • Follow Best Practices lined out in our Contributor Docs