[20582] Cal.com Update to V2 version#20698
Merged
Merged
Conversation
Describe the bug Cal.com's deprecated V1 API endpoints are still being used internally, causing integration failures. Despite V1 being marked as deprecated, the system continues to make calls to V1 endpoints, resulting in errors when attempting to use Cal.com integrations. To Reproduce Steps to reproduce the behavior: Set up any Cal.com integration Attempt to trigger an action that uses the Cal.com API that arent V2 (e.g., create booking, fetch availability, sync calendars) Observe that the integration fails with errors Check the API calls being made - they reference deprecated V1 endpoints Expected behavior All Cal.com integrations should use the current V2 API endpoints. When V1 was deprecated, all internal systems and integrations should have been migrated to V2 to ensure continued functionality. Additional context Cal.com announced the deprecation of their V1 API, but appears to still be relying on V1 endpoints in their current implementation. This creates a critical issue where: Integrations fail automatically Users cannot reliably connect Cal.com with other services The deprecation appears incomplete, leaving users with broken functionality This needs to be addressed by completing the migration from V1 to V2 across all Cal.com systems and integrations. Guide for migrating to v2: https://cal.com/docs/api-reference/v2/v1-v2-differences PipedreamHQ#20582
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
dannyroosevelt
moved this to Ready for PR Review
in Component (Source and Action) Backlog
Collaborator
|
Thank you so much for submitting this! We've added it to our backlog to review, and our team has been notified. |
Collaborator
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughConsolidates Cal.com integration to API v2: removes duplicate v2 action, migrates actions/sources and client helpers to v2 endpoints/UIDs, updates props and webhook handling, adds location-types helper, and bumps component/package versions. Changes
Sequence Diagram(s)sequenceDiagram
participant Action as Action (create/get-slots/cancel)
participant App as calCom.app client
participant API as Cal.com API (v2)
Action->>App: call client method (createBooking / listBookings / cancelBooking / getBookableSlots) with params + $ context
App->>API: HTTP request to v2 endpoint (bookings/... or slots/...) with cal-api-version header
API-->>App: v2 response (response.data, response.pagination)
App-->>Action: return normalized response (uid-based fields, pagination flags)
Action-->>Action: set $summary and return result
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
components/cal_com/cal_com.app.mjs (1)
12-27:⚠️ Potential issue | 🟡 Minor
bookingIdpropDefinition is mislabeled/described after the UID migration.The value emitted by
options()is nowbooking.uid(a string, line 24), but the prop name/label is still "Booking ID" and the description says "The identifier of the booking to retrieve" — which is both too narrow (also used for cancel) and misleading (it's a UID now, not the numericid). For AI-agent consumption per the guidelines, include a concrete inline example and clarify it's a UID.📝 Suggested description refinement
- label: "Booking ID", - description: "The identifier of the booking to retrieve", + label: "Booking UID", + description: "The unique identifier (UID) of the booking, e.g. `booking_uid_123`. Used by Cal.com v2 endpoints for fetching, cancelling, and rescheduling bookings.",Renaming the prop key (
bookingId→bookingUid) would be a breaking change for existing workflows and is optional; updating the label/description alone is non-breaking.As per coding guidelines: "Prop
descriptionfields must be written for AI agent consumption: Include concrete inline examples for non-obvious formats (JSON objects, IDs, dates, enums); Avoid UI-centric language."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@components/cal_com/cal_com.app.mjs` around lines 12 - 27, The propDefinition bookingId (in the bookingId object, options() implementation and listBookings() usage) still uses UI-centric label "Booking ID" and a misleading description; update the label to something like "Booking UID" (or "Booking UID (string)") and rewrite the description to state that the value is the booking.uid string (include a concrete inline example, e.g. "e.g. \"a1b2c3d4-uid\"") and note it is the unique UID used across endpoints (used for retrieval/cancellation) without renaming the prop key to avoid breaking changes; keep options() mapping to booking.uid unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/cal_com/actions/create-booking/create-booking.mjs`:
- Around line 53-57: The current UTC check using this.start.endsWith("Z") in
create-booking (which throws ConfigurationError) is too permissive and rejects
valid "+00:00" offsets; replace it with a stricter ISO-8601 UTC validation:
parse this.start into a Date/ISO parser (or use a library like Luxon) and verify
it produces a valid date and that its canonical toISOString() ends with "Z" (or
accept and normalize "+00:00" to "Z") before proceeding; if
parsing/normalization fails, throw the existing ConfigurationError with a clear
message indicating the expected ISO-8601 UTC format.
- Around line 23-51: The refactor removed several previously-supported props
causing breaking changes; restore the old prop keys as optional props (e.g.,
name, email, title, startTime, endTime, recurringCount, top-level language and
timeZone, and request-body props like metadata, location, customInputs, guests,
lengthInMinutes, bookingFieldsResponses) alongside the new
attendeeName/attendeeEmail/attendeeTimeZone/attendeeLanguage/start props in
create-booking.mjs so existing workflows continue to work; mark them optional,
accept the same shapes as before, and pass them through into the request payload
(e.g., the data object used when creating bookings) letting `@pipedream/platform`
axios strip undefined values, and also add a short migration note in the PR
description or changelog calling out the breaking change.
- Around line 70-81: The summary currently uses response?.data?.id which is
wrong for v2 and breaks for recurring bookings; update the success path after
calling this.calCom.createBooking to extract the booking UID by checking
response.data for either a single BookingOutput (use response.data.uid) or an
array (use the first element's uid or include a count), then call
$.export("$summary", ...) with the UID (or "n bookings created" if array) so the
summary always surfaces the booking.uid used by
getBooking/deleteBooking/reschedule; ensure you still return response and keep
the $.export on every success path.
In `@components/cal_com/actions/delete-booking/delete-booking.mjs`:
- Around line 5-6: The action's metadata is inconsistent: the code uses the
cancellation endpoint but the metadata fields name and description still say
"Delete Booking" and "Delete an existing booking…"; update the description
string (leave the name and key unchanged to avoid breaking compatibility) to
accurately describe cancellation (e.g., start with "Cancel an existing booking
by its UID…" and mention the POST /bookings/{uid}/cancel behavior) so it aligns
with the $summary ("cancelled") and the actual behavior of the action.
- Around line 40-45: Replace the manual assembly and guards for the request body
with a single object that includes the optional props directly: build data = {
cancellationReason: this.cancellationReason, cancelSubsequentBookings:
this.cancelSubsequentBookings } and pass it to
this.calCom.deleteBooking(this.bookingId, data, $); rely on `@pipedream/platform`
axios to strip undefined so you no longer need the if checks around
cancellationReason or cancelSubsequentBookings.
In `@components/cal_com/actions/get-bookable-slots/get-bookable-slots.mjs`:
- Around line 59-68: The "format" prop currently exposes bare string options;
change its options array to labeled option objects to improve UX by mapping
values to human-friendly labels: update the options for the format prop (the
object with type: "string", label: "Format", description: ... ) so each entry is
{ label: "<friendly text>", value: "<time|range>" } (e.g., { label: "Start times
only", value: "time" } and { label: "Start and end times", value: "range" }) and
ensure any consuming code that reads format options uses the value field.
- Around line 77-92: Collapse the per-property guards when building the params
object in get-bookable-slots.mjs: create params with all optional fields
(eventTypeId, eventTypeSlug, username, timeZone, duration, format,
bookingUidToReschedule) set directly from this.* (e.g. params = { start:
this.start, end: this.end, eventTypeId: this.eventTypeId, ... }) and pass that
to this.calCom.getBookableSlots({ params, $ }); `@pipedream/platform`'s axios will
strip undefined values so you can remove the individual if (...) checks and
simplify the method.
In `@components/cal_com/cal_com.app.mjs`:
- Around line 169-179: Rename the method deleteBooking to cancelBooking in the
CalCom app module and update its usages: in the method definition currently
named deleteBooking (which calls POST bookings/{bookingUid}/cancel), change the
name to cancelBooking; then update the caller in delete-booking.mjs to call
cancelBooking instead of deleteBooking and ensure parameter names
(cancellationReason, cancelSubsequentBookings) and logging remain unchanged.
Also search for any other references to deleteBooking and replace them with
cancelBooking to keep the API verb consistent; optionally consider changing the
component name/annotations (delete-booking.mjs and its
annotations.destructiveHint) to reflect "Cancel Booking" if you want to align UI
wording with the API operation.
---
Outside diff comments:
In `@components/cal_com/cal_com.app.mjs`:
- Around line 12-27: The propDefinition bookingId (in the bookingId object,
options() implementation and listBookings() usage) still uses UI-centric label
"Booking ID" and a misleading description; update the label to something like
"Booking UID" (or "Booking UID (string)") and rewrite the description to state
that the value is the booking.uid string (include a concrete inline example,
e.g. "e.g. \"a1b2c3d4-uid\"") and note it is the unique UID used across
endpoints (used for retrieval/cancellation) without renaming the prop key to
avoid breaking changes; keep options() mapping to booking.uid unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 875d9bfe-511c-428c-b117-2587f274be9a
📒 Files selected for processing (13)
components/cal_com/actions/create-booking-v2/create-booking-v2.mjscomponents/cal_com/actions/create-booking/create-booking.mjscomponents/cal_com/actions/delete-booking/delete-booking.mjscomponents/cal_com/actions/get-all-bookings/get-all-bookings.mjscomponents/cal_com/actions/get-bookable-slots/get-bookable-slots.mjscomponents/cal_com/actions/get-booking/get-booking.mjscomponents/cal_com/cal_com.app.mjscomponents/cal_com/package.jsoncomponents/cal_com/sources/booking-cancelled/booking-cancelled.mjscomponents/cal_com/sources/booking-created/booking-created.mjscomponents/cal_com/sources/booking-ended/booking-ended.mjscomponents/cal_com/sources/booking-rescheduled/booking-rescheduled.mjscomponents/cal_com/sources/common/common.mjs
💤 Files with no reviewable changes (1)
- components/cal_com/actions/create-booking-v2/create-booking-v2.mjs
fixing the review comments
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
components/cal_com/cal_com.app.mjs (2)
12-27:⚠️ Potential issue | 🟡 MinorUpdate
bookingIdpropDefinition to reflect UID semantics.The option
valueis nowbooking.uid, notbooking.id, and v2 endpoints (getBooking,cancelBooking) all key off the UID. Thelabel/descriptionstill say "Booking ID" / "identifier of the booking to retrieve", which is misleading for agents — it implies a numeric/database ID and only mentions retrieval (the prop is shared by cancel and get).Consider renaming to
bookingUid(with the underlying prop key kept for backward compatibility if the deployed prop name matters) and updating description with format guidance, e.g.:♻️ Suggested change
bookingId: { type: "string", - label: "Booking ID", - description: "The identifier of the booking to retrieve", + label: "Booking UID", + description: "The UID of the booking, e.g. `8s3K9Lp2qR`. Cal.com v2 identifies bookings by UID rather than numeric ID.", async options({ filterCancelled = false }) {Same applies to
eventTypeIddescription (Line 31) — clarify it is the numeric event type ID with a concrete example.As per coding guidelines: "prop descriptions should explicitly state required formats (IDs/UIDs, ISO timestamps...) and include concrete examples for non-obvious inputs."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@components/cal_com/cal_com.app.mjs` around lines 12 - 27, Update the bookingId propDefinition to clarify it expects a UID (not a numeric DB id): rename the user-facing prop to bookingUid (but keep bookingId as the underlying key if deployed prop names must remain compatible), update the label to "Booking UID" and the description to state the UID format (e.g., "UID string, e.g. `bkg_abc123def456`") and note it is used by getBooking and cancelBooking; ensure options still map value to booking.uid and that listBookings is used to populate choices. Also update eventTypeId's description to explicitly state it's a numeric event type ID with an example (e.g., "12345").
89-98:⚠️ Potential issue | 🟠 MajorDon't wrap platform axios errors in
ConfigurationError.Every API error from
_makeV2Requestis caught and re-thrown asConfigurationError, which:
- Violates the action-guideline rule that
ConfigurationErroris reserved for pre-flight validation of user inputs — not API errors.@pipedream/platformaxios already surfaces HTTP errors with the original message and status, and that is what callers (and agents) expect.- Strips the HTTP status code, response body, and error stack — making 4xx vs 5xx indistinguishable for retry policies and obscuring diagnostic info.
- Makes every Cal.com 4xx/5xx look like a misconfiguration to the user, which is misleading (e.g., transient 5xx, rate limit 429, race conditions).
The retry layer is already inside this method; just let the final error propagate.
🛡️ Suggested fix
- try { - return await this._withRetries(() => axios($, config)); - } catch (error) { - const apiMessage = - error?.response?.data?.error?.message || - error?.response?.data?.message || - error?.message || - "Unknown Cal.com API error"; - throw new ConfigurationError(apiMessage); - } + return this._withRetries(() => axios($, config));If
ConfigurationErroris no longer needed in this file after the change, the import can be narrowed toimport { axios } from "@pipedream/platform";.As per coding guidelines: "Errors should throw naturally; do not wrap
run()in a blanket try/catch —@pipedream/platformaxios surfaces HTTP errors automatically with the API's original message;ConfigurationErroris appropriate only for pre-call validation of user configuration mistakes."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@components/cal_com/cal_com.app.mjs` around lines 89 - 98, The try/catch in _makeV2Request is wrapping axios errors and rethrowing them as ConfigurationError; remove the try/catch so the error from this._withRetries(() => axios($, config)) propagates naturally (preserving HTTP status, response body and stack) and update any imports: remove ConfigurationError if no longer used and narrow the import to { axios } from "@pipedream/platform". Ensure _withRetries and _makeV2Request signatures remain unchanged and no other code expects a ConfigurationError from this method.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/cal_com/actions/create-booking/create-booking.mjs`:
- Around line 177-188: The prop descriptions for metadata and
bookingFieldsResponses in create-booking.mjs are missing concrete JSON examples;
update the metadata field description to include an inline example showing a
simple key-value JSON (e.g. {"company":"ACME","source":"referral"}) and note the
constraints (max 50 keys, key name ≤40 chars, value ≤500 chars), and update the
bookingFieldsResponses description to include an inline example showing
field-slug-to-response mapping (e.g.
{"dietary_restrictions":"vegetarian","company_size":"10-50"}) so callers know
the expected shape; make these edits on the metadata and bookingFieldsResponses
property objects in the file (preserve existing labels, types, and optional:
true).
- Around line 70-147: The props marked as required (start, attendeeName,
attendeeEmail, attendeeTimeZone) break the documented legacy fallbacks; make
these v2 props optional and add cross-field validation in run() to enforce the
fallback logic: set start, attendeeName, attendeeEmail, attendeeTimeZone to
optional: true in the props block and in run() (the function resolving
resolvedStart = this.start || this.startTime and attendeeName/email/timeZone
fallbacks) implement explicit checks that pick the v2 prop or the legacy prop
(e.g., resolvedStart = this.start || this.startTime), and validate that at least
one contact is present (attendeeEmail || attendeePhoneNumber || this.email) and
throw a clear error if not; update any error messages to reflect the
combined/legacy options.
- Around line 39-44: The prop schema marks eventTypeId as required which blocks
the slug-based flow; make eventTypeId optional (set optional: true on the
eventTypeId propDefinition) so the existing XOR check in run() (the eventTypeId
vs eventTypeSlug+username/teamSlug validation around lines 285–287) can run and
enforce the mutual-exclusivity at runtime; leave the XOR validation in run()
unchanged.
In `@components/cal_com/actions/get-bookable-slots/get-bookable-slots.mjs`:
- Line 97: Update the static summary export so it includes the total slot count:
when building $.export("$summary", ...) compute the total by iterating over the
response `data` object (the date-keyed groups returned by the Cal.com v2 slots
endpoint) and summing the lengths of each array, then set the summary string to
include that number (e.g. "Successfully retrieved X available slots") instead of
the current static message.
---
Outside diff comments:
In `@components/cal_com/cal_com.app.mjs`:
- Around line 12-27: Update the bookingId propDefinition to clarify it expects a
UID (not a numeric DB id): rename the user-facing prop to bookingUid (but keep
bookingId as the underlying key if deployed prop names must remain compatible),
update the label to "Booking UID" and the description to state the UID format
(e.g., "UID string, e.g. `bkg_abc123def456`") and note it is used by getBooking
and cancelBooking; ensure options still map value to booking.uid and that
listBookings is used to populate choices. Also update eventTypeId's description
to explicitly state it's a numeric event type ID with an example (e.g.,
"12345").
- Around line 89-98: The try/catch in _makeV2Request is wrapping axios errors
and rethrowing them as ConfigurationError; remove the try/catch so the error
from this._withRetries(() => axios($, config)) propagates naturally (preserving
HTTP status, response body and stack) and update any imports: remove
ConfigurationError if no longer used and narrow the import to { axios } from
"@pipedream/platform". Ensure _withRetries and _makeV2Request signatures remain
unchanged and no other code expects a ConfigurationError from this method.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: a7b3457d-01b8-4e13-9188-8d7a1b59c451
📒 Files selected for processing (5)
components/cal_com/actions/create-booking/create-booking.mjscomponents/cal_com/actions/delete-booking/delete-booking.mjscomponents/cal_com/actions/get-bookable-slots/get-bookable-slots.mjscomponents/cal_com/cal_com.app.mjscomponents/cal_com/common/location-types.mjs
fix for the coderabbitai review comments
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
components/cal_com/actions/create-booking/create-booking.mjs (1)
281-286:⚠️ Potential issue | 🟡 MinorVerify the recurring-booking summary path.
This summary assumes
response.datais always a single booking object. If the v2 create-booking API returns multiple occurrences forbookingType === "recurring", the success message loses the chainable identifier and degrades to the generic fallback.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@components/cal_com/actions/create-booking/create-booking.mjs` around lines 281 - 286, The summary export assumes response.data is a single object; update the logic around bookingUid and the $.export("$summary", ...) call to handle v2 recurring bookings where response.data may be an array: detect if response?.data is an array and, in that case, pick the primary occurrence UID (e.g., response.data[0].uid or the chainable identifier field) or join multiple UIDs into the summary so the chainable identifier is preserved for recurring bookings; adjust any variables referencing bookingUid accordingly (bookingUid, response) and ensure the fallback still works when data is missing.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/cal_com/actions/create-booking/create-booking.mjs`:
- Around line 236-247: The current validation (hasSlugIdentifier) only ensures
at least one identifier but allows mixed or conflicting identifiers; update the
validation in the create-booking flow to reject mixed identifier paths: if
eventTypeId is provided, throw a ConfigurationError when any of eventTypeSlug,
username, teamSlug, or organizationSlug are also present; likewise, if using
slug-based identification, throw a ConfigurationError when both username and
teamSlug are present (they are alternatives). Apply this logic where
hasSlugIdentifier is computed and before building the data payload so only a
single, non-conflicting identifier set (either eventTypeId or one slug path) is
allowed.
- Around line 170-209: additionalProps() currently only affects the UI, so
update the runtime builder _buildLocation() to validate that for each
this.location case the corresponding field (locationAddress, locationValue,
locationPhone, locationIntegration) is present and well-formed before returning
the location object; if a required field is missing or invalid, throw or return
a clear, descriptive error (including the location type and missing field) so
non-UI callers get a 4xx with actionable details; also apply the same runtime
validation for the recurring case (this.bookingType === "recurring") to ensure
recurrenceCount is within expected bounds before proceeding.
In `@components/cal_com/actions/delete-booking/delete-booking.mjs`:
- Around line 8-10: Update the action annotations to reflect that this performs
an irreversible cancellation by changing the annotations.destructiveHint value
from false to true in the delete-booking action (i.e., modify the annotations
block that currently contains "destructiveHint: false" to "destructiveHint:
true"); leave other flags like openWorldHint as appropriate and run tests/lints
to ensure the updated annotation passes validation.
---
Duplicate comments:
In `@components/cal_com/actions/create-booking/create-booking.mjs`:
- Around line 281-286: The summary export assumes response.data is a single
object; update the logic around bookingUid and the $.export("$summary", ...)
call to handle v2 recurring bookings where response.data may be an array: detect
if response?.data is an array and, in that case, pick the primary occurrence UID
(e.g., response.data[0].uid or the chainable identifier field) or join multiple
UIDs into the summary so the chainable identifier is preserved for recurring
bookings; adjust any variables referencing bookingUid accordingly (bookingUid,
response) and ensure the fallback still works when data is missing.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 46fd4847-7821-4f32-a7cc-e6447d7ee532
📒 Files selected for processing (10)
components/cal_com/actions/create-booking/create-booking.mjscomponents/cal_com/actions/delete-booking/delete-booking.mjscomponents/cal_com/actions/get-all-bookings/get-all-bookings.mjscomponents/cal_com/actions/get-bookable-slots/get-bookable-slots.mjscomponents/cal_com/actions/get-booking/get-booking.mjscomponents/cal_com/package.jsoncomponents/cal_com/sources/booking-cancelled/booking-cancelled.mjscomponents/cal_com/sources/booking-created/booking-created.mjscomponents/cal_com/sources/booking-ended/booking-ended.mjscomponents/cal_com/sources/booking-rescheduled/booking-rescheduled.mjs
coderabbitai review changes done
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
components/cal_com/actions/delete-booking/delete-booking.mjs (1)
8-12:⚠️ Potential issue | 🟡 Minor
destructiveHint: truecontradicts the established rationale for this action.Based on learnings from prior review discussions,
destructiveHint: falsewas determined to be correct because Cal.com V2's cancellation flow marks the booking as "cancelled" rather than permanently deleting it from the system. This is considered a soft/status-change operation, not a permanent delete.The current code has
destructiveHint: true, which appears to contradict that conclusion.🔧 Suggested fix per prior discussion
annotations: { - destructiveHint: true, + destructiveHint: false, openWorldHint: true, readOnlyHint: false, },Based on learnings: "In
components/cal_com/actions/delete-booking/delete-booking.mjs,destructiveHint: falseis intentional. Cal.com V2 replaces hard deletion with a cancellation flow (POST bookings/{uid}/cancel) that marks the booking as 'cancelled' rather than removing it from the system."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@components/cal_com/actions/delete-booking/delete-booking.mjs` around lines 8 - 12, The annotations object in delete-booking.mjs incorrectly sets destructiveHint: true; change it to destructiveHint: false to reflect that this action performs a cancellation/status change (POST bookings/{uid}/cancel) rather than a permanent delete—update the annotations block where destructiveHint is defined so it reads false while leaving openWorldHint and readOnlyHint unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/cal_com/actions/create-booking/create-booking.mjs`:
- Around line 211-230: The _buildLocation() method currently validates
location-specific properties but returns only { type: this.location }, so the
actual location data never gets sent; update _buildLocation to include the
appropriate field based on this.location: when "attendeeAddress" add address:
this.locationAddress, when "attendeeDefined" add location: this.locationValue,
when "attendeePhone" add phone: this.locationPhone, and when "integration" add
integration: this.locationIntegration (preserve existing ConfigurationError
checks and always include type).
---
Outside diff comments:
In `@components/cal_com/actions/delete-booking/delete-booking.mjs`:
- Around line 8-12: The annotations object in delete-booking.mjs incorrectly
sets destructiveHint: true; change it to destructiveHint: false to reflect that
this action performs a cancellation/status change (POST bookings/{uid}/cancel)
rather than a permanent delete—update the annotations block where
destructiveHint is defined so it reads false while leaving openWorldHint and
readOnlyHint unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3bf4e94f-bbe0-4c3d-a1b3-4b1bf0363faf
📒 Files selected for processing (2)
components/cal_com/actions/create-booking/create-booking.mjscomponents/cal_com/actions/delete-booking/delete-booking.mjs
adding the location object values
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
components/cal_com/actions/create-booking/create-booking.mjs (1)
257-266:⚠️ Potential issue | 🟠 MajorReject any slug-related fields when
eventTypeIdis set.Line 265 only compares
eventTypeIdwith a fully-formed slug path. Payloads likeeventTypeId + eventTypeSlug,eventTypeId + organizationSlug, oreventTypeId + usernamestill pass and are then forwarded unchanged bycomponents/cal_com/cal_com.app.mjs:149-158, so the action still accepts mixed identifier inputs it claims to forbid.🛠️ Proposed fix
const hasEventTypeId = Boolean(this.eventTypeId); + const hasAnySlugFields = Boolean( + this.eventTypeSlug || this.username || this.teamSlug || this.organizationSlug, + ); const hasPersonalSlug = Boolean(this.eventTypeSlug && this.username); const hasTeamSlug = Boolean(this.eventTypeSlug && this.teamSlug); const hasSlugIdentifier = hasPersonalSlug || hasTeamSlug; if (this.username && this.teamSlug) { throw new ConfigurationError("Provide Username or Team Slug with Event Type Slug, not both."); } - if (hasEventTypeId === hasSlugIdentifier) { + if (hasEventTypeId && hasAnySlugFields) { + throw new ConfigurationError("Provide Event Type ID by itself, without Event Type Slug, Username, Team Slug, or Organization Slug."); + } + if (!hasEventTypeId && !hasSlugIdentifier) { throw new ConfigurationError("Provide either Event Type ID, or Event Type Slug with Username/Team Slug, but not both."); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@components/cal_com/actions/create-booking/create-booking.mjs` around lines 257 - 266, The current check (hasEventTypeId === hasSlugIdentifier) lets mixed payloads like eventTypeId + eventTypeSlug/username/teamSlug/organizationSlug slip through; update the validation in create-booking to explicitly reject any slug-related fields when eventTypeId is present and still require one identifier: if hasEventTypeId and any of this.eventTypeSlug, this.username, this.teamSlug, or this.organizationSlug are truthy, throw ConfigurationError; also ensure the converse that if no eventTypeId and no slug identifier is provided you throw as well (use the existing hasPersonalSlug/hasTeamSlug/hasSlugIdentifier and hasEventTypeId symbols to implement these explicit checks).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/cal_com/actions/create-booking/create-booking.mjs`:
- Around line 18-21: Update the bookingType prop description to remove
UI-centric phrasing and instead list the accepted string values and any
companion properties that must be provided when each value is used (e.g., which
additional props are required for a "one-off" vs "recurring" booking); locate
the bookingType property in create-booking.mjs and replace "Select the type..."
with a concise, value-oriented description that enumerates allowed values and
names the related props callers must include, and do the same for the other prop
description block referenced in the review (the similar prop group near the
other prop definitions) so all description fields are written for AI/agent
consumption rather than interactive UI instructions.
---
Duplicate comments:
In `@components/cal_com/actions/create-booking/create-booking.mjs`:
- Around line 257-266: The current check (hasEventTypeId === hasSlugIdentifier)
lets mixed payloads like eventTypeId +
eventTypeSlug/username/teamSlug/organizationSlug slip through; update the
validation in create-booking to explicitly reject any slug-related fields when
eventTypeId is present and still require one identifier: if hasEventTypeId and
any of this.eventTypeSlug, this.username, this.teamSlug, or
this.organizationSlug are truthy, throw ConfigurationError; also ensure the
converse that if no eventTypeId and no slug identifier is provided you throw as
well (use the existing hasPersonalSlug/hasTeamSlug/hasSlugIdentifier and
hasEventTypeId symbols to implement these explicit checks).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: ebdc3cb4-b8e0-4254-82d7-b52ddd1a6695
📒 Files selected for processing (1)
components/cal_com/actions/create-booking/create-booking.mjs
changes with respect to the param description
GTFalcao
reviewed
Apr 28, 2026
Collaborator
GTFalcao
left a comment
GTFalcao
left a comment
There was a problem hiding this comment.
There are a few components that did not have required props changed or added, so they don't need a major version increase, just minor or patch.
If their return value / schema changed with the API migration, then we should keep the major version bump - if not, we should adjust it.
| optional: true, | ||
| }, | ||
| }, | ||
| async additionalProps() { |
Collaborator
There was a problem hiding this comment.
Can we remove additionalProps() and simply have all of these as regular props? Their description can start with something like "Used only if Prop Name is set" (to denote which prop they're relevant to).
This improves compatibility with MCP use cases
| version: "0.0.6", | ||
| name: "Cancel Booking", | ||
| description: "Cancel an existing booking by its UID. Note: Cal.com v2 replaces the v1 delete endpoint with a cancellation flow; the booking is marked cancelled rather than removed. [See the documentation](https://cal.com/docs/api-reference/v2/bookings/cancel-a-booking)", | ||
| version: "1.0.0", |
Collaborator
There was a problem hiding this comment.
Did the return value (schema) change between V1 and V2? If not, we don't need to do a major version bump here - the component's config isn't changing in a backwards-incompatible way.
addressed the review comments provided
GTFalcao
approved these changes
May 5, 2026
GTFalcao
moved this from Ready for PR Review
to Ready for QA
in Component (Source and Action) Backlog
Contributor
|
QA testing results: All the actions are working perfectly ✅ Just 1 minor detail:
|
github-project-automation
Bot
moved this from Ready for QA
to Done
in Component (Source and Action) Backlog
e11man
pushed a commit
to RoboSourceTeam/pipedream
that referenced
this pull request
May 15, 2026
* [20582] Cal.com Update to V2 version Describe the bug Cal.com's deprecated V1 API endpoints are still being used internally, causing integration failures. Despite V1 being marked as deprecated, the system continues to make calls to V1 endpoints, resulting in errors when attempting to use Cal.com integrations. To Reproduce Steps to reproduce the behavior: Set up any Cal.com integration Attempt to trigger an action that uses the Cal.com API that arent V2 (e.g., create booking, fetch availability, sync calendars) Observe that the integration fails with errors Check the API calls being made - they reference deprecated V1 endpoints Expected behavior All Cal.com integrations should use the current V2 API endpoints. When V1 was deprecated, all internal systems and integrations should have been migrated to V2 to ensure continued functionality. Additional context Cal.com announced the deprecation of their V1 API, but appears to still be relying on V1 endpoints in their current implementation. This creates a critical issue where: Integrations fail automatically Users cannot reliably connect Cal.com with other services The deprecation appears incomplete, leaving users with broken functionality This needs to be addressed by completing the migration from V1 to V2 across all Cal.com systems and integrations. Guide for migrating to v2: https://cal.com/docs/api-reference/v2/v1-v2-differences PipedreamHQ#20582 * fixing the review comments fixing the review comments * fix for the coderabbitai review comments fix for the coderabbitai review comments * coderabbitai review changes done coderabbitai review changes done * adding the location object values adding the location object values * changes with respect to the param description changes with respect to the param description * addressed the review comments provided addressed the review comments provided
michelle0927
pushed a commit
that referenced
this pull request
Jun 2, 2026
* [20582] Cal.com Update to V2 version Describe the bug Cal.com's deprecated V1 API endpoints are still being used internally, causing integration failures. Despite V1 being marked as deprecated, the system continues to make calls to V1 endpoints, resulting in errors when attempting to use Cal.com integrations. To Reproduce Steps to reproduce the behavior: Set up any Cal.com integration Attempt to trigger an action that uses the Cal.com API that arent V2 (e.g., create booking, fetch availability, sync calendars) Observe that the integration fails with errors Check the API calls being made - they reference deprecated V1 endpoints Expected behavior All Cal.com integrations should use the current V2 API endpoints. When V1 was deprecated, all internal systems and integrations should have been migrated to V2 to ensure continued functionality. Additional context Cal.com announced the deprecation of their V1 API, but appears to still be relying on V1 endpoints in their current implementation. This creates a critical issue where: Integrations fail automatically Users cannot reliably connect Cal.com with other services The deprecation appears incomplete, leaving users with broken functionality This needs to be addressed by completing the migration from V1 to V2 across all Cal.com systems and integrations. Guide for migrating to v2: https://cal.com/docs/api-reference/v2/v1-v2-differences #20582 * fixing the review comments fixing the review comments * fix for the coderabbitai review comments fix for the coderabbitai review comments * coderabbitai review changes done coderabbitai review changes done * adding the location object values adding the location object values * changes with respect to the param description changes with respect to the param description * addressed the review comments provided addressed the review comments provided
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Describe the bug
Cal.com's deprecated V1 API endpoints are still being used internally, causing integration failures. Despite V1 being marked as deprecated, the system continues to make calls to V1 endpoints, resulting in errors when attempting to use Cal.com integrations. To Reproduce
Steps to reproduce the behavior:
Set up any Cal.com integration
Attempt to trigger an action that uses the Cal.com API that arent V2 (e.g., create booking, fetch availability, sync calendars) Observe that the integration fails with errors
Check the API calls being made - they reference deprecated V1 endpoints
Expected behavior
All Cal.com integrations should use the current V2 API endpoints. When V1 was deprecated, all internal systems and integrations should have been migrated to V2 to ensure continued functionality.
Additional context
Cal.com announced the deprecation of their V1 API, but appears to still be relying on V1 endpoints in their current implementation. This creates a critical issue where:
Integrations fail automatically
Users cannot reliably connect Cal.com with other services The deprecation appears incomplete, leaving users with broken functionality
This needs to be addressed by completing the migration from V1 to V2 across all Cal.com systems and integrations.
Guide for migrating to v2: https://cal.com/docs/api-reference/v2/v1-v2-differences
#20582
Summary by CodeRabbit
Removed Features
New Features
Updates