feat: add missing event type fields for advanced settings in api v2

[dhairyashiil]

What does this PR do?

Adds 8 missing event type fields to API v2 that are available in the production app (tRPC) but were not exposed in the platform API.

New Fields Added

Field	Type	Description
disableCancelling	boolean	Disable cancelling for guests and organizer
disableRescheduling	boolean	Disable rescheduling for guests and organizer
canSendCalVideoTranscriptionEmails	boolean	Send Cal Video transcription emails after meetings
autoTranslateInstantMeetingTitleEnabled	boolean	Auto-translate instant meeting titles using AI
interfaceLanguage	string	Preferred language for the booking interface
allowReschedulingPastBookings	boolean	Allow rescheduling of past events
allowReschedulingCancelledBookings	boolean	Allow booking through reschedule link for cancelled bookings
showOptimizedSlots	boolean	Arrange time slots to optimize availability

Changes

• Output Schema: Added fields to BaseEventTypeOutput_2024_06_14
• Input Schemas: Added fields to CreateEventTypeInput and UpdateEventTypeInput
• Output Service: Updated transformation to include new fields in API responses
• Organizations Output Service: Updated to support new fields for team event types
• E2E Tests: Extended existing tests to cover all new fields

Videos

1. create event type:

https://github.com/user-attachments/assets/bc9cf3eb-35d1-4bd6-a3b5-7ff7515622aa

2. get single event type:

https://github.com/user-attachments/assets/eb75bd82-87ea-488c-b719-3d2c934edea7

3. get all event types:

https://github.com/user-attachments/assets/03b5e09a-c03a-4f9f-ba14-6a839742f7d0

4. update single event type:

https://github.com/user-attachments/assets/63aea169-1329-4daa-8dfe-ff00bcc08bc3

5. delete single event type:

https://github.com/user-attachments/assets/e8e93e91-12da-4a01-85ce-41c9e68a208c

6. Validation for interfaceLanguage:

https://github.com/user-attachments/assets/bdbae79b-e73f-47b8-8517-e83089cf8f79

Note: Later I removed customReplyToEmail intentionally from this PR in commit. The website restricts this field to only allow the user's own verified emails via a dropdown, but implementing the same validation in the API requires additional logic. This will be addressed in a separate PR with proper email ownership validation.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
cal-companion	Ready	Preview	Comment	Dec 10, 2025 10:46am

2 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
cal	Ignored			Dec 10, 2025 10:46am
cal-eu	Ignored			Dec 10, 2025 10:46am

[dhairyashiil]

Hey @dhairyashiil! 👋 Nice PR! I've left a small suggestion about adding email validation for customReplyToEmail to prevent invalid values from causing email delivery issues downstream

Actually, I removed customReplyToEmail from this PR 😅 because the website restricts this field to the user’s own verified emails through a dropdown. Implementing the same validation in the API would require additional logic. I might address this in a separate PR with proper email ownership validation.

thank you for the review @pedroccastro : )

[pedroccastro]

Actually, I removed customReplyToEmail from this PR 😅 because the website restricts this field to the user’s own verified emails through a dropdown. Implementing the same validation in the API would require additional logic. I might address this in a separate PR with proper email ownership validation.

thank you for the review @pedroccastro : )

Appreciate the context on customReplyToEmail, that makes sense! 👍 The tests are a bit verbose, but they’re consistent with the current pattern. I think a refactor to reduce duplication/complexity would be great for maintainability. Happy to track that as a follow-up PR since it might get out of scope here. Overall, looks good to me!

[dhairyashiil]

Can we handle both changes in separate follow-up PRs later? I need to focus on getting the companion app ready before Dec 15 😅

1. Changing disableRescheduling and disableCancelling to objects
2. Moving canSendCalVideoTranscriptionEmails into calVideoSettings?

and added default values to all the new fields:

Field	Default
disableCancelling	false
disableRescheduling	false
canSendCalVideoTranscriptionEmails	true
autoTranslateInstantMeetingTitleEnabled	false
allowReschedulingPastBookings	false
allowReschedulingCancelledBookings	false
showOptimizedSlots	false

These defaults match the actual behavior on the website when creating a new event type.

[supalarry]

Can we handle both changes in separate follow-up PRs later? I need to focus on getting the companion app ready before Dec 15 😅

1. Changing disableRescheduling and disableCancelling to objects
2. Moving canSendCalVideoTranscriptionEmails into calVideoSettings?

and added default values to all the new fields:

Field Default disableCancelling false disableRescheduling false canSendCalVideoTranscriptionEmails true autoTranslateInstantMeetingTitleEnabled false allowReschedulingPastBookings false allowReschedulingCancelledBookings false showOptimizedSlots false These defaults match the actual behavior on the website when creating a new event type.

API changes are hard to make later on - people might start using them and then we either need to:

1. introduce a new possible type for disableRescheduling thus making it more confusing for users and the boolean option forever will be considered the old way, but we will need to keep it because what if someone uses it.
2. deprecate canSendCalVideoTranscriptionEmails and hide it from docs but leave it in code because what if someone uses it

So when making an API it's better to just get it right the first time because later on we can't change api interface in a way that breaks it for existing users without creatinga new version of it.

I think 2 things above will take like 20 minutes to implement. We already have CalVideoSettings property so we just move property there and extract it from there and for disableRescheduling we create it as object instead - example is:

@ApiPropertyOptional({
    type: Routing,
    description:
      "Routing information from routing forms that determined the booking assignment. Both responseId and teamMemberIds are required if provided.",
    example: {
      responseId: 123,
      teamMemberIds: [101, 102],
    },
  })
  @IsOptional()
  @ValidateNested()
  @Type(() => Routing)
  routing?: Routing;