Skip to main content

Cal.com Destination

Nexla's bi-directional connectors allow data to flow both to and from any location, making it simple to create a FlexFlow data flow that sends data to a Cal.com location.
cal_com_api.png

Cal.com

Create a Cal.com Destination​

  1. Click the + icon on the Nexset that will be sent to the Cal.com destination, and select the Send to Destination option from the menu.

  2. Select the Cal.com connector from the list of available destination connectors. Then, select the credential that will be used to connect to the Cal.com account, and click Next; or, create a new Cal.com credential for use in this flow.

  3. In Nexla, Cal.com destinations can be created using pre-built endpoint templates, which expedite destination setup for common Cal.com endpoints. Each template is designed specifically for the corresponding Cal.com endpoint, making destination configuration easy and efficient.
    • To configure this destination using a template, follow the instructions in Configure Using a Template.

    Cal.com destinations can also be configured manually, allowing you to send data to Cal.com endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
    • To configure this destination manually, follow the instructions in Configure Manually.

Configure Using a Template​

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Cal.com endpoints. Each template is designed specifically for the corresponding Cal.com endpoint, making destination setup easy and efficient.

  • To configure this destination using a template, select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.

    Create a Booking

    This endpoint creates a new booking against an event type. Use it to programmatically book meetings from upstream systems — for example, when a lead in a CRM requests a demo, when an AI scheduling assistant resolves a meeting time, or when an internal tool needs to confirm a meeting on a teammate's calendar.

    • Each record in the upstream Nexset must include start (the booking start time in ISO 8601 format, for example 2026-06-01T15:00:00Z), eventTypeId (the numeric ID of the event type to book — obtainable from the List Event Types source endpoint), and an attendee object containing the attendee's name, email, and timeZone.
    • The full record is sent as the JSON body of the POST /v2/bookings call. Use the Nexla transform layer to shape upstream attributes into the field names expected by Cal.com.
    • The template sends the cal-api-version: 2026-02-25 header on each request, which selects the latest v2 contract for the /v2/bookings endpoint.
    • To create a recurring booking, pass the ID of a recurring event type in eventTypeId. To create an instant meeting on a team event type, include "instant": true in the body.

    Use the Get Available Slots source endpoint to confirm the chosen start time is still bookable before issuing the create call. For complete payload reference, see the Cal.com Create a booking reference.

    Cancel a Booking

    This endpoint cancels an existing booking. Cal.com fires its booking-cancellation webhook to any subscribed listeners and notifies attendees by email.

    • Enter the booking UID in the Booking UID field. This field is required. Booking UIDs can be obtained from the List Bookings source endpoint or from upstream Nexla data flows.
    • The body of each POST /v2/bookings/{'{uid}'}/cancel call may include an optional cancellationReason string (a human-readable reason that is surfaced to attendees) and an optional cancelSubsequentBookings boolean (used for recurring bookings to cancel the remaining occurrences in the series).
    • The template sends the cal-api-version: 2026-02-25 header on each request.

    Because cancellation triggers attendee notifications and is generally irreversible, validate upstream data carefully before activating this destination. Consider routing through a Nexla transform that filters to only the bookings that should genuinely be canceled.

    Reschedule a Booking

    This endpoint moves an existing booking to a new start time. Cal.com fires its booking-rescheduled webhook for any subscribed listeners and notifies attendees by email.

    • Enter the booking UID in the Booking UID field. This field is required.
    • The body of each POST /v2/bookings/{'{uid}'}/reschedule call must include a start field with the new booking start time in ISO 8601 format. Optionally, include a reschedulingReason string explaining the change.
    • The template sends the cal-api-version: 2026-02-25 header on each request.

    Before rescheduling, call the Get Available Slots source endpoint with the booking's event type and a window around the proposed new time to confirm the slot is still available.

    Confirm a Booking

    This endpoint confirms a pending booking on an event type that requires manual approval. Use it to wire approval decisions from an internal review tool, helpdesk, or workflow engine back into Cal.com.

    • Enter the booking UID in the Booking UID field. This field is required. Only bookings on event types with the "requires confirmation" flag enabled will be in a pending state and eligible for this call.
    • The body of the POST /v2/bookings/{'{uid}'}/confirm call is typically empty, but Cal.com accepts an optional reason field. Use the Nexla transform layer to add this field if your approvers should be quoted in the confirmation email.
    • The template sends the cal-api-version: 2026-02-25 header on each request.

    To reject a pending booking instead of confirming it, use the Cancel a Booking destination with an explanatory cancellationReason. For complete details, see the Cal.com Confirm a booking reference.

    Create an Event Type

    This endpoint creates a new event type — the bookable service that clients schedule against. Use it to provision event types programmatically as part of an onboarding flow, or to keep Cal.com event types in sync with an upstream catalog.

    • Each record in the upstream Nexset must include title (the display name of the event type), slug (the URL-safe identifier used in the public booking link), and lengthInMinutes (the duration of each booking). Optional fields include description, locations, bookingFields, and scheduleId.
    • The full record is sent as the JSON body of the POST /v2/event-types call.
    • The template sends the cal-api-version: 2024-06-14 header on each request, which selects the stable v2 contract for the /v2/event-types endpoint.

    Event type slugs must be unique within an account. For complete details on supported fields and validation rules, see the Cal.com Create an event type reference.

    Update an Event Type

    This endpoint updates an existing event type's configuration — useful for syncing duration changes, description updates, location changes, or schedule reassignments from a downstream system of record back into Cal.com.

    • Enter the event type ID in the Event Type ID field. This field is required. Event type IDs can be obtained from the List Event Types source endpoint.
    • The body of each PATCH /v2/event-types/{'{id}'} call carries the fields to update. Include only the fields that should change — omitted fields are left untouched.
    • The template sends the cal-api-version: 2024-06-14 header on each request.

    Changing the slug of an event type changes its public booking URL and will break any existing booking links pointing at the previous slug. For complete details, see the Cal.com Update an event type reference.

    Delete an Event Type

    This endpoint deletes an event type by ID. Deleting an event type removes it from your public booking page and prevents future bookings against it. Existing bookings on the event type are preserved.

    • Enter the event type ID in the Event Type ID field. This field is required.
    • The DELETE /v2/event-types/{'{id}'} call sends no body — the upstream record drives only the URL parameter.
    • The template sends the cal-api-version: 2024-06-14 header on each request.

    Deletion is irreversible. Consider archiving the event type by toggling its hidden flag (via the Update an Event Type destination) before permanently deleting it.

    Create a Schedule

    This endpoint creates a new availability schedule. Schedules define the recurring working hours that drive what time slots are bookable for the event types they are attached to. Use this endpoint to provision schedules programmatically during user onboarding, or to apply a standard set of working hours across a team.

    • Each record in the upstream Nexset must include name (the display name of the schedule), timeZone (an IANA timezone identifier, for example America/New_York), and availability (an array of weekly availability ranges, each with a list of days and a start/end time).
    • The full record is sent as the JSON body of the POST /v2/schedules call.
    • The template sends the cal-api-version: 2024-06-11 header on each request.

    Each Cal.com user can have multiple schedules but only one default schedule at a time. For complete details on the availability payload shape, see the Cal.com Create a schedule reference.

    Create a Webhook

    This endpoint registers a new webhook subscription with Cal.com. Use it to programmatically subscribe a Nexla webhook source (or any external listener) to booking events without manually configuring webhooks in the Cal.com UI.

    • Each record in the upstream Nexset must include subscriberUrl (the HTTPS URL where Cal.com should POST the event payload) and triggers (an array of event names to subscribe to, for example ["BOOKING_CREATED", "BOOKING_RESCHEDULED", "BOOKING_CANCELLED"]). The active field defaults to true.
    • Optionally include secret (a shared secret used to HMAC-sign each webhook delivery, allowing the receiver to verify authenticity) and payloadTemplate (a custom payload template).
    • The full record is sent as the JSON body of the POST /v2/webhooks call.

    Always provide a secret for production webhooks and validate the signature on every received delivery. For complete details, see the Cal.com Create a webhook reference.

    Create an Out-of-Office Entry

    This endpoint creates a new out-of-office (OOO) entry for the authenticated user. OOO entries block availability for a date range and optionally forward bookings to another teammate. Use this endpoint to sync OOO from a workforce-management system, HRIS, or shared calendar into Cal.com.

    • Each record in the upstream Nexset must include start (the start date of the OOO period in ISO 8601 format) and end (the end date in ISO 8601 format). Optional fields include reason (a short label such as vacation or training), notes (free-text notes shown to the OOO user), and toUserId (the numeric user ID of a teammate to forward incoming bookings to).
    • The full record is sent as the JSON body of the POST /v2/out-of-office call.

    For complete details on the OOO payload shape, see the Cal.com Create an out-of-office entry reference.

Configure Manually​

Cal.com destinations can be manually configured to send data to any valid Cal.com API v2 endpoint. Manual configuration provides maximum flexibility for endpoints not covered by pre-built templates, including team and organization endpoints, custom URL patterns, or any endpoint that requires a specific cal-api-version header.

Using manual configuration, you can also configure Nexla to automatically send the response received from the Cal.com API after each call to a new Nexla webhook data source. This is particularly useful for capturing the booking UID returned by Create a Booking, the event type ID returned by Create an Event Type, or the webhook ID returned by Create a Webhook.

API Method​

  1. To manually configure this destination, select the Advanced tab at the top of the configuration screen.

  2. Select the API method that will be used for calls to the Cal.com API from the Method pulldown menu. Common methods for Cal.com write endpoints include:

    • POST: For creating resources or triggering state changes (for example, POST /v2/bookings, POST /v2/event-types, POST /v2/bookings/{'{uid}'}/cancel)
    • PATCH: For partial updates to existing resources (for example, PATCH /v2/event-types/{'{id}'})
    • PUT: For full replacement updates where supported by Cal.com
    • DELETE: For removing resources (for example, DELETE /v2/event-types/{'{id}'})

Data Format​

  1. Select the format in which the Nexset data will be sent to the Cal.com API from the Content Format pulldown menu. The Cal.com API v2 expects application/json for all write endpoints, so JSON is the appropriate choice for every Cal.com destination.

API Endpoint URL​

  1. Enter the URL of the Cal.com API endpoint to which you want to send the Nexset data in the URL field. All Cal.com v2 API URLs use the base https://api.cal.com/v2/ followed by the resource path. For update or state-change operations, include the booking UID or numeric ID at the end of the URL — Nexla macros can substitute the value from each upstream record (for example, {'https://api.cal.com/v2/bookings/{uid}/cancel'}).

Request Headers​

Optional

  • If Nexla should include any additional request headers in API calls to this destination, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (for example, header1:value1,header2:value2).

    Cal.com v2 endpoints version their contracts using the cal-api-version header. To pin a write call to a specific contract version, add a header such as cal-api-version:2026-02-25 (for bookings endpoints) or cal-api-version:2024-06-14 (for event-types endpoints). Each Cal.com endpoint documents its current version in the Cal.com API v2 reference.

    You do not need to include the Authorization header or the Content-Type header — Nexla adds Authorization: Bearer ${'{API_KEY}'} automatically based on your Cal.com credential, and adds Content-Type: application/json based on the selected Content Format.

Exclude Attributes from the Call​

Optional

  • If any record attributes in the Nexset should be omitted when sending data to this Cal.com destination, select the attributes from the Exclude Attributes pulldown menu. This is useful for stripping internal Nexla bookkeeping fields, or for omitting upstream IDs that Cal.com would reject as unknown.

  • Any number of attributes can be selected for exclusion, and all excluded attributes will be shown in the field. To remove an attribute from the list, click the X icon next to the attribute name.

Record Batching​

Optional

The Cal.com API v2 does not natively support batched create/update calls — each booking, event type, or webhook is created with its own request. Record batching in Nexla is therefore best left disabled for Cal.com destinations.

  1. To override the default and group records into a single batched payload anyway, check the box next to Would you like to batch your records together?.

  2. Enter the maximum number of records that should be batched together in a single API call in the Batch Size field. By default, this value is set to 100.

  3. Select the algorithm that will be used to group records into batches from the Grouping Algorithm pulldown menu. The sample request shown in the panel on the right will be updated to reflect the current batching settings.

Response Webhook​

Optional

Nexla can automatically send the response received from the Cal.com API after each call to a new Nexla webhook data source. This option allows you to keep track of the status of each API call and downstream-process the resource IDs returned by Cal.com.

  • To enable this option, check the box next to Would you like to process the API response as a Nexla Webhook source?.

    Enabling the response webhook is particularly useful for Create a Booking (to capture the new booking UID), Create an Event Type (to capture the new event type ID), and Create a Webhook (to capture the new webhook subscription ID for later management).

Sample Request Payload​

Sample request payloads containing a portion of the Nexset data that will be sent to the Cal.com API endpoint based on the current settings are shown in the Sample Payload panel on the right. These samples can be referenced to ensure that the destination and request settings are correctly configured.

  • Click on a sample request payload to expand it and view the complete payload content.

  • Sample payloads are automatically updated with each setting change, making it easy to verify that changes achieve the desired effect.

Endpoint Testing (Manual Configuration)​

After all endpoint settings have been configured, Nexla can send a test payload to the Cal.com API to ensure that the destination is configured correctly.

  1. To send a test payload, select the Test button at the top of the Sample Payload panel, and click on a listed sample payload to expand it.

  2. If any modifications to the sample payload are needed, make the necessary changes directly within the sample window.

  3. Click the Send Test Data button at the top of a sample payload to send the test payload to the Cal.com API using the current settings.

Important

Test payloads sent to write endpoints (such as Create a Booking, Cancel a Booking, or Delete an Event Type) make real, irreversible changes in your Cal.com account and may notify attendees by email. Use a separate test Cal.com account before sending test data against a production account.

Save & Activate the Destination​

  • Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To begin sending data to Cal.com, open the destination resource menu, and select Activate.

    The Nexset data will not be sent to Cal.com until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.