What does this PR do?

Migrates BOOKING_REQUESTED webhook delivery from the legacy inline path (getWebhooks → sendPayload) to the producer–consumer pipeline (Trigger.dev or sync), so it uses the same flow as other booking triggers (e.g. BOOKING_CREATED, BOOKING_RESCHEDULED).

Core Changes

• handleBookingRequested.ts: Replaced inline getWebhooks → sendPayload with getWebhookProducer().queueBookingRequestedWebhook(...). Missing evt.uid is handled with if/else + inner try/catch so workflow scheduling is never skipped. Added oAuthClientId parameter for platform webhook subscriber filtering.
• RegularBookingService: When a booking requires confirmation (!isConfirmedByDefault), the BOOKING_REQUESTED webhook is queued via deps.webhookProducer.queueBookingRequestedWebhook(...). Queued after booking update so the consumer fetches complete booking data (location, metadata, references).
• handlePaymentSuccess.ts: Now passes oAuthClientId through to handleBookingRequested so platform webhooks fire for paid events requiring confirmation.
• DI wiring: webhookProducer is wired into RegularBookingService.module.ts via webhookProducerModuleLoader.
• API v2 Integration: Added WEBHOOK_PRODUCER injection token in regular-booking.tokens.ts and useFactory: () => getWebhookProducer() in RegularBookingModule to bridge Cal.com DI into NestJS. RegularBookingService (API v2) now receives and forwards the producer via @Inject(WEBHOOK_PRODUCER).
• BookingWebhookDataFetcher: Upgraded from scaffold to full implementation — fetches booking via BookingRepository.getBookingForCalEventBuilderFromUid(), builds CalendarEvent via CalendarEventBuilder.fromBooking(), and returns complete data for webhook payload building. Now accepts platform metadata fields (platformClientId, platformRescheduleUrl, etc.).
• Webhook task payload schema: Extended bookingWebhookTaskPayloadSchema with platformClientId, platformRescheduleUrl, platformCancelUrl, platformBookingUrl.
• Platform library exports: IWebhookProducerService, getWebhookProducer, Tasker, and getTasker are now exported from @calcom/platform-libraries.
• Trigger.dev config: Tuned to small-1x machine, concurrencyLimit: 25, retry with 30s–600s exponential backoff and OOM fallback to medium-1x.
• E2E (webhook.e2e.ts): Added null guard for body.payload.metadata to prevent crash when metadata is absent.

BOOKING_REQUESTED Routes (2 entry points, both migrated)

Test Changes

Removed legacy tests that asserted inline webhook delivery (sendPayload / expectBookingRequestedWebhookToHaveBeenFired):

• 8 tests from fresh-booking.test.ts, reschedule.test.ts, collective-scheduling.test.ts

Added new test suites (49 total tests):

Integration test scenarios (8 total in webhook-producer-booking-requested.test.ts):

1. Basic confirmation → queueBookingRequestedWebhook called
2. Booker-is-organizer + confirmation → still called
3. Confirmation threshold NOT met → not called (BOOKING_CREATED instead)
4. Confirmation threshold IS met → called
5. Paid event + confirmation → called after payment succeeds
6. Reschedule + confirmation (non-organizer) → called (not BOOKING_RESCHEDULED)
7. Reschedule + confirmation (organizer) → not called (BOOKING_RESCHEDULED instead)
8. Collective scheduling + confirmation → called

Payload content verification tests (11 new tests in booking-requested.test.ts):

• Verifies PENDING status and BOOKING_REQUESTED triggerEvent
• Verifies eventTitle, eventDescription, requiresConfirmation, price, currency, length
• Verifies bookingId, title, location, organizer, attendees
• Verifies response label normalization (name → your_name, email → email_address)
• Verifies metadata handling (empty object when absent, includes videoCallUrl when present)
• Verifies attendee firstName/lastName derivation from full name
• Verifies assignmentReason uses legacy array format from booking
• Verifies default values (price: 0, currency: "usd", length: null)
• Verifies destinationCalendar as null when not set
• Verifies paid event payload structure

Reusable test infrastructure:

• packages/testing/src/lib/webhookProducer.ts — MockWebhookProducer type, createMockWebhookProducer(), expectWebhookProducerCalled(), expectWebhookProducerNotCalled(), resetMockWebhookProducer() for extendable use as more triggers migrate.

Updates Since Last Revision

Code review findings (migration quality score: 8.5/10):

• ✅ All BOOKING_REQUESTED routes are covered (non-payment and payment paths)
• ✅ No performance pitfalls identified — producer is lightweight, consumer runs async
• ✅ Subscriber filtering params are consistent across both entry points
• ⚠️ handleBookingRequested uses getWebhookProducer() container getter instead of DI injection (acceptable for standalone function; would need refactoring to class/service for proper DI)
• ⚠️ buildDTO switch only handles BOOKING_REQUESTED (expected for incremental migration; other triggers will be added as they migrate)

Backward compatibility verified:

• Webhook payload shape matches legacy format (v2021-10-20)

• assignmentReason uses legacy array format from booking

• Response labels normalized (name → your_name, email → email_address)

• Default values preserved (price: 0, currency: "usd", length: null)

• Fixes #XXXX

• Fixes CAL-XXXX

Visual Demo (For contributors especially)

Video Demo (if applicable):

Loom

• Before: BOOKING_REQUESTED webhook is sent inline via handleWebhookTrigger; no task appears in Trigger.dev.
• After: Create a booking that requires confirmation → BOOKING_REQUESTED is queued via producer → when Trigger.dev is configured, a webhook.deliver run appears in the Trigger.dev dashboard.

Image Demo (if applicable):

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

1. Environment: For Trigger.dev path: ENABLE_ASYNC_TASKER=true, TRIGGER_SECRET_KEY, TRIGGER_API_URL set; worker running.
2. Minimal setup: One event type with "Requires confirmation" enabled; at least one webhook subscriber for BOOKING_REQUESTED.
3. Happy path:
   • Create a booking for that event type.
   • Expected: BOOKING_REQUESTED webhook is received by the subscriber.
   • With Trigger.dev: a webhook.deliver task run appears in the dashboard.
4. Run tests:

   TZ=UTC yarn test packages/features/webhooks/lib/__tests__
   TZ=UTC yarn vitest run packages/features/bookings/lib/handleNewBooking/test/webhook-producer-booking-requested.test.ts

Human Review Checklist

• Verify handleBookingRequested.ts if/else + inner try/catch ensures workflows always run (lines 75-94)
• Verify paid event test (scenario 5) actually exercises the post-payment webhook path — note that handleBookingRequested.ts uses getWebhookProducer() directly, which may not be intercepted by the DI-injected mock in RegularBookingService
• Confirm webhook payload shape is backward-compatible (especially assignmentReason, responses normalization, default values)
• Verify the 11 new payload verification tests in booking-requested.test.ts adequately cover the payload shapes that were verified by the deleted tests
• Consider removing 11 overlapping tests identified in code review (6 from payload builder section, 5 from consumer scenario section) in a follow-up PR
• Note: This PR is large (39 files, +2725/-1639 lines) — consider whether any parts could be split

Checklist

• I haven't read the contributing guide
• My code doesn't follow the style guidelines of this project
• I haven't commented my code, particularly in hard-to-understand areas
• I haven't checked if my changes generate no new warnings
• My PR is too large (>500 lines or >10 files) and should be split into smaller PRs

Link to Devin run: https://app.devin.ai/sessions/0e475005d5fd4c30a7fcc9c464f091a3
Requested by: ali@cal.com (@alishaz-polymath)