Cal.com
Open-source scheduling, attributed end to end.
Cal.com webhooks report the full booking lifecycle: created, rescheduled, cancelled, rejected. Apointo turns those states into distinct events and lets you decide which one becomes the advertising conversion.
Pages marked Planned are complete specifications written before the connector ships. They validate demand. Connectors with real delivery logs are marked Production or Beta.
Bookings without history are just intent
A booked slot says someone intended to show up. Without cancellations and attendance in the same ledger, bidding treats every booking as equal and pays for the ones that never happened.
The lifecycle becomes distinct events
Each webhook state maps to its own canonical event. Reschedules keep identity attached. Cancellations retract by rule. You choose whether booked or attended feeds optimization, per destination.
- 01Ad click lands on the booking page
- 02UTM and click ids captured at booking time
- 03Booking webhooks reach Apointo
- 04Reschedules and cancellations update the record
- 05Attended meetings become the conversion you chose
Subscribe the booking webhooks from your Cal.com app.
Capture utm parameters and click ids at booking time.
Map lifecycle states to canonical events once.
Cancellations follow your retraction rule automatically.
| From | Apointo |
|---|---|
| BOOKING_CREATED | appointment_booked |
| Marked attended (via your workflow) | appointment_attended |
| BOOKING_CANCELLED | appointment_cancelled (retracts booked signal) |
How is this different from the Calendly connector?
Different provider, different API, same discipline: lifecycle states stay distinct events instead of one generic booking signal.
Do reschedules create duplicate conversions?
No. The reschedule updates the existing record; the conversion follows the meeting, not each webhook.
When does this connector ship?
This page is the working specification. Join the early-access list and build order follows demand.