Cal com integration: bookings succeed but never trigger workflows. Engineer requesting request headers

Bookings created through the native Cal com integration (Book on the Calendar tool) work correctly: calendar entry created, native confirmation email sends. But SMS workflows NEVER fire on these bookings, while identical bookings made through the Cal com web page trigger workflows every time.

Verified on my side across a week of testing: attendee phone lands in the smsReminderNumber booking field in plus-one format, attendee email is a valid non-organizer address, workflows live under the correct team, SMS credits funded, paid Teams plan. Web bookings text. Integration bookings never do, and credits are never deducted, so the send is never attempted.

Cal com support has escalated this to their engineering. Their engineer’s specific request: the full API request Retell sends to the v2 bookings endpoint, including headers, especially the cal-api-version header. The request is constructed server-side so I cannot capture it from my dashboard.

Could someone from the team share the request format, with the API key redacted?

References:
Cal com booking IDs created by the integration: 22923476 and 22924437
Example call ID with successful booking: call_348e8f5d07cdb6d27a01c19e555

The Cal com support thread is active now, so this would unblock engineers on both sides.

Hello @ulicrz84 Could you please share your Agent ID? This will help us investigate the issue further.

Thank You

Hi Shah,

Here is the Agent ID for Bella Luxe
agent_6c37a0459ccefcf898bb286df5

@ulicrz84 I have reported this to the team for further investigation. We’ll get back to you as soon as we have an update.

Thank You

Thank you for your help Shah.

Hello @ulicrz84 This issue should be checked with the Cal.com team, as the SMS workflow runs on the Cal.com side not ours.

Thank You

Thank you Shah.

Agreed, and Cal.com’s engineering is actively on it now.

Your support team’s request-format documentation was exactly what their engineer needed, it’s confirmed the payload is correct and narrowed their investigation to how their API version controller processes it.

Appreciate the quick responses on your side.