Skip to main content
Webhooks offer a great way to automate the flow with other apps when invitees schedule, cancel or reschedule events, or when the meeting ends.
The webhook subscription allows you to listen to specific trigger events, such as when a booking has been scheduled, for example. You can always listen to the webhook by providing a custom subscriber URL with your own development work. However, if you wish to trigger automations without any development work, you can use the integration with Zapier which connects Cal.com to your apps.

Webhook scope levels

Webhooks can be created at multiple levels of scope, each determining which events they apply to:
  • User-level: Triggers for all event types owned by the user (excluding team-managed types).
  • Event-type level: Triggers only for a specific event type. Useful for fine-grained control.
  • Team-level: Applies to team event types (i.e., Collective and Round Robin) within the specified team.
    In the case of Managed events, bookings are made on the child event types, not the parent team event. Because of this, team-level webhooks will not trigger for managed events unless one of the following is true:
    • You create a webhook directly on the parent event type (recommended), or
    • You create individual webhooks on the child event types (owned by users).
    💡 Note: Users can create webhooks that apply to their own event types, including child events under a managed event, even if a team-level webhook exists.
  • Organization-level: Applies to all team event types across all teams within the organization.

Creating a webhook subscription

To create a new webhook subscription, visit /settings/developer/webhooks and proceed to enter the following details:
  1. Subscriber URL: The listener URL where the payload will be sent to, when an event trigger is triggered. The subscriber URL must meet the following requirements:
    • Cal.com SaaS: Only HTTPS URLs are accepted. HTTP, private/internal IP addresses (e.g., 10.x.x.x, 192.168.x.x, 127.0.0.1), and localhost are blocked.
    • Self-hosted: Both HTTP and HTTPS URLs are accepted, and private IP addresses are allowed for internal webhooks.
    • All environments: Cloud metadata endpoints (e.g., 169.254.169.254) and non-HTTP protocols (e.g., ftp://, file://) are always blocked.
    If your subscriber URL does not meet these requirements, the webhook creation request will be rejected with an error.
  2. Event triggers: You can decide which triggers specifically to listen to. Currently, we offer listening to Booking Cancelled, Booking Created, Booking Rescheduled, Booking Rejected, Booking Requested, Booking Paid, Booking Payment Initiated, Booking No-Show Updated, Meeting Started, Meeting Ended, Recording Ready, Recording Transcription Generated, Instant Meeting Created, Instant Meeting Accepted, Out of Office Created, After Hosts Cal Video No-Show, After Guests Cal Video No-Show, Form Submitted, Form Submitted (No Event), Calendar Entry Rejected, and Delegation Credential Rotation Required.
  3. Secret: You can provide a secret key with this webhook and then verify it on the subscriber URL when receiving a payload to confirm if the payload is authentic or adulterated. You can leave it blank, if you don’t wish to secure the webhook with a secret key.
  4. Custom Payload: You have the option to customize the payload you receive when a subscribed event is triggered.

Expectations with the triggers

Seated event types

For event types with seats enabled, the attendees array in webhook payloads contains only the attendee associated with the specific seat that triggered the webhook. For example, when a new seat is booked, the webhook includes only that seat’s attendee — not all attendees across the entire booking. This applies to all booking-related triggers (BOOKING_CREATED, BOOKING_RESCHEDULED, etc.).

Example webhook payloads

Most webhook events use a nested payload format with booking details inside a payload object. The MEETING_STARTED and MEETING_ENDED events use a different flat format where booking fields are at the top level.

Booking events (nested format)

Events like BOOKING_CREATED, BOOKING_CANCELLED, BOOKING_RESCHEDULED, and most other triggers use this format:

Meeting started / meeting ended (flat format)

MEETING_STARTED and MEETING_ENDED webhooks use a flat payload format where booking fields are at the top level alongside triggerEvent, rather than nested inside a payload object. These webhooks are delivered at the scheduled start and end time of the meeting respectively.
MEETING_STARTED and MEETING_ENDED webhooks do not support custom payload templates. They always send the full booking data in the flat format shown above.
If a booking is cancelled or rescheduled before the meeting time, the scheduled MEETING_STARTED and MEETING_ENDED webhooks for that booking are automatically cancelled.

Instant meeting accepted

The INSTANT_MEETING_ACCEPTED webhook fires when a host accepts an instant meeting request through the connect-and-join flow. It only triggers for the first host to accept — if another host has already accepted the booking, the webhook is not sent again. This trigger is available for team event types only. The payload includes the booking status (set to ACCEPTED), the accepting host as the organizer with their locale and time format preferences, the guest attendees list, booking responses, and a metadata object containing the videoCallUrl for the meeting.

Calendar entry rejected

The CALENDAR_ENTRY_REJECTED webhook fires when an external attendee declines a Cal.com event from their connected Google Calendar or Microsoft 365 calendar. Cal.com detects the decline during calendar sync and dispatches the webhook once per attendee per booking — duplicate syncs do not re-fire the trigger, so you can rely on it as an at-most-once signal. Use this trigger when you want to react to attendee declines that happen outside Cal.com, for example to notify the host, update a CRM, or offer the attendee a reschedule link. The webhook resolves subscribers at the user, event type, team, and organization levels, so any matching subscription receives the payload. The payload uses a flat format with booking, calendarEvent, and declinedAttendee objects at the top level:
The provider field is google_calendar or office365_calendar depending on where the decline originated.

Subscriber URL requirements

Cal.com validates webhook subscriber URLs to protect against server-side request forgery (SSRF). The validation rules depend on whether you are using Cal.com Cloud or a self-hosted instance. Cal.com Cloud:
  • The subscriber URL must use HTTPS.
  • URLs pointing to private or internal IP addresses (such as 10.x.x.x, 172.16.x.x, 192.168.x.x, or 127.0.0.1) are blocked.
  • Cloud metadata endpoints (such as 169.254.169.254) are blocked.
  • Hostnames that resolve to private IP addresses via DNS are also blocked.
Self-hosted:
  • Both HTTP and HTTPS URLs are accepted, so you can use internal services as webhook targets.
  • Private IP addresses are allowed for internal webhooks.
  • Cloud metadata endpoints are still blocked for security, since self-hosted instances may run on cloud infrastructure.
If your subscriber URL does not meet these requirements, the webhook creation or update request will fail with a 400 error indicating the URL is not allowed.

Verifying the authenticity of the received payload

  1. Simply add a new secret key to your webhook and save.
  2. Wait for the webhook to be triggered (event created, cancelled, rescheduled, or meeting ended)
  3. Use the secret key to create an hmac, and update that with the webhook payload received to create an SHA256.
  4. Compare the hash received in the header of the webhook (X-Cal-Signature-256) with the one created using the secret key and the body of the payload. If they don’t match, the received payload was adulterated and cannot be trusted.

Adding a custom payload template

Customizable webhooks are a great way reduce the development effort and in many cases remove the need for a developer to build an additional integration service. An example of a custom payload template is provided here:
where {{type}} represents the event type slug and {{title}} represents the title of the event type. Note that the variables should be added with a double parenthesis as shown above. Here’s a breakdown of the payload that you would receive via an incoming webhook, with an exhaustive list of all the supported variables provided below:

Webhook variable list

Organizer Structure

Attendee Structure