Connecting Cal.com to Meta Conversions API
Cal.com holds the booking and, unusually, will let you self-host and query the database directly. Meta's pixel loses a large share of conversions to Safari, ad blockers and iOS, and the Conversions API exists because of it. The join between them succeeds or fails on one thing: whether the fbc and fbp values reaches the Cal.com booking before the conversion happens, because Meta can only match a conversion it can tie back to a click it recognizes.
Free30 minutesNo obligation
Specific to this pair
Cal.com to Meta CAPI: Schedule events from BOOKING_CREATED
Send Meta's Schedule event from Cal.com's BOOKING_CREATED webhook with hashed email and name, fbc and fbp from hidden booking questions, and an event_id derived from the booking uid. Fire any browser Schedule from the embed's booking-success listener with that ID, not a Cal.com pixel app. Add value for paid types, and send held meetings promptly.
Meta has a standard event built for this pair: Schedule. Fire it from the BOOKING_CREATED webhook with the attendee's email and name hashed, the fbc and fbp values passed into hidden booking questions through prefill parameters, and an event_id derived from the booking uid, so a pixel Schedule fired on your side deduplicates against it.
The cross-origin problem is sharper for Meta than elsewhere, because fbp is a first-party cookie on your domain and the Cal.com embed cannot read it. Without it Meta still matches on hashed email, but Event Match Quality drops. If you run a Meta pixel app inside Cal.com and a server send, the event_ids will not match, since the app knows nothing about your server's id. Run one or the other, or fire the pixel yourself from the embed's booking-success listener on your page, where you control the event_id.
For paid event types, add value and currency to Schedule, or send Purchase when the payment completes. Cancellations cannot be retracted in Meta, so if they are common, send a second custom event when the meeting is actually held and optimize on that, sending it right after the meeting ends with that time as event_time. A weekly batch of held meetings will hit Meta's seven-day limit on website events and lose the oldest.
Cal.com → Meta · what breaks
Why this join usually fails — Cal.com → Meta
- 01
The fbc and fbp values never reaches Cal.com
As with any hosted booking page, the identifier must be passed on the booking URL and captured into a booking question. Cal.com's routing forms add a second surface that also needs to carry it, and they are commonly missed.
- 02
Routing forms are a second capture surface
Cal.com routing forms sit in front of the booking and are easy to forget. An identifier captured on the booking page but not on the routing form leaves a hole in exactly the traffic that used routing.
- 03
Double counting from broken deduplication
Server and browser both fire, the event_id does not match, and Meta counts two purchases. Reported ROAS goes up, the business does not, and it can run for months before anyone reconciles against the store.
- 04
Nothing reconciles afterwards
Events Manager shows received events, the deduplication state and an Event Match Quality score per event. Events arriving is not the test — deduplicated, well-matched events arriving is. Compare Meta's reported purchases against your store's order count for the same window.
Cal.com → Meta · the fix
What working looks like — Cal.com → Meta
The fbc and fbp values on every booking
Conversions arriving in Meta
Events appear in Events Manager with an Event Match Quality score, deduplicated against the pixel, and become usable for optimization and attribution.
Reconciled against the source
Cal.com → Meta · architecture
How Cal.com and Meta actually connect
- 1
Cal.com holds the truth
The booking carries the attendee, the event type, the time and any custom booking-question responses. Self-hosted instances give you direct database access, which makes reconciliation genuinely easy compared with every other booking tool.
- 2
Meta Conversions API needs a click to match
Meta matches server events to people using whatever identifiers you send, hashed with SHA-256 where required. There is no single mandatory key, which is why quality varies so much between implementations — a poorly matched event is accepted, reported, and worth much less than it appears.
- 3
The identifier is the bridge
The fbc and fbp values, captured at the visit and carried into the Cal.com booking.
- 4
The event source decides reliability
Send from your server on the webhook, and handle BOOKING_CANCELLED for reversals. Self-hosted instances can read from the database instead, which is the most reliable option available on any booking platform.
- 5
Deduplication at the destination
Meta deduplicates on the pair of event_name and event_id. The browser pixel and the server event must send the same event_id for the same conversion, within the deduplication window. Get this wrong and every purchase counts twice — which is by far the most common Conversions API failure and it inflates reported ROAS rather than reducing it.
Cal.com → Meta · normal or broken
Working vs. broken, side by side — Cal.com → Meta
Normal, not a fault
The fbc and fbp values present on the booking
Sent from the BOOKING_CREATED webhook
Deduplicated correctly
Meta deduplicates on the pair of event_name and event_id. The browser pixel and the server event must send the same event_id for the same conversion, within the deduplication window. Get this wrong and every purchase counts twice — which is by far the most common Conversions API failure and it inflates reported ROAS rather than reducing it.
Reconciles with the source
Actually broken
The fbc and fbp values missing on most records
As with any hosted booking page, the identifier must be passed on the booking URL and captured into a booking question. Cal.com's routing forms add a second surface that also needs to carry it, and they are commonly missed.
Sent from the browser
Cal.com routing forms sit in front of the booking and are easy to forget. An identifier captured on the booking page but not on the routing form leaves a hole in exactly the traffic that used routing.
Counted twice, or not at all
Server and browser both fire, the event_id does not match, and Meta counts two purchases. Reported ROAS goes up, the business does not, and it can run for months before anyone reconciles against the store.
Nobody has reconciled it
Cal.com → Meta · diagnose
Diagnostic order — Cal.com → Meta
- 01
Count bookings carrying the fbc and fbp values
- 02
Follow one real conversion end to end
- 03
Query recent bookings for the identifier field
Direct database query on self-hosted, API on cloud. Then repeat for bookings that came through a routing form specifically.
- 04
Read Event Match Quality and the deduplication indicator
In Events Manager, open the event and check both. A low match quality means weak identifiers; a missing deduplication indicator means your event_id pairing is broken.
- 05
Read the match rate, not the success message
Events Manager shows received events, the deduplication state and an Event Match Quality score per event. Events arriving is not the test — deduplicated, well-matched events arriving is. Compare Meta's reported purchases against your store's order count for the same window.
Cal.com → Meta · prove
How it gets proven — Cal.com → Meta
Source of truth
Cal.com's bookings list for the same window, with cancellations separated.
- The fbc and fbp values confirmed present on a live booking.
- Deduplication confirmed in Events Manager on a real purchase, with the browser and server events visibly paired rather than counted twice.
- Coverage confirmed separately for direct bookings and for routing-form bookings.
Cal.com → Meta · free audit
What we check in the free audit
- Count bookings carrying the fbc and fbp values
- Follow one real conversion end to end
- Query recent bookings for the identifier field
- Read Event Match Quality and the deduplication indicator
- Read the match rate, not the success message
Checked against
Cal.com's bookings list for the same window, with cancellations separated.
Free30 minutesNo obligation
Cal.com → Meta · when not to buy
When you don't need this — Cal.com → Meta
- Measure identifier coverage yourself first — pull your last hundred bookings and count how many carry the fbc and fbp values.
- Self-hosting Cal.com already gives you the data. If you have engineering capacity in-house, this is one of the few integrations a competent developer can genuinely do alone.
- If you are not running Meta ads at meaningful spend, the Conversions API is effort without payoff. It earns its cost when the optimization signal is worth improving.
Cal.com → Meta · what we deliver
What gets built — Cal.com → Meta
Identifier capture into Cal.com
Add a hidden booking question, append the identifier via Cal.com's prefill query parameters, and verify through the API or directly in the database on a self-hosted instance.
Event source: the BOOKING_CREATED webhook
Send from your server on the webhook, and handle BOOKING_CANCELLED for reversals. Self-hosted instances can read from the database instead, which is the most reliable option available on any booking platform.
Dispatch to Meta
Server-side events to the Conversions API with the event_id matched to the pixel, action_source set correctly, and customer data hashed before it leaves your infrastructure.
Reversals where they exist
BOOKING_CANCELLED and BOOKING_REJECTED both fire with the reference, so reversals are straightforward.
Written guarantee
95%+ tracking accuracy
Measured against Cal.com's bookings list for the same window, with cancellations separated.. Miss it and we keep working at no cost.
From $400 · See packages
FAQ
Cal.com → Meta questions, answered
Schedule, from the BOOKING_CREATED webhook. Add a separate custom event for meetings actually held if no-shows are high.
Usually because fbc and fbp never reached the embed, so Meta is matching on hashed email alone. Prefill them into hidden booking questions.
Almost always because the fbc and fbp values never reached the Cal.com booking. As with any hosted booking page, the identifier must be passed on the booking URL and captured into a booking question. Cal.com's routing forms add a second surface that also needs to carry it, and they are commonly missed. Measure coverage before debugging the dispatch.
Two things. The _fbc cookie, derived from the fbclid parameter on the landing URL in the format fb.1.<timestamp>.<fbclid>, is the click identifier. The _fbp cookie is the browser identifier. Beyond those, Meta matches on hashed customer information — email, phone, name, city, country — and every additional field raises the Event Match Quality score. Unlike Google, Meta does not need a click ID at all if the customer data is good, but match quality drops noticeably without it.
The BOOKING_CREATED webhook. Send from your server on the webhook, and handle BOOKING_CANCELLED for reversals. Self-hosted instances can read from the database instead, which is the most reliable option available on any booking platform.
Events Manager shows received events, the deduplication state and an Event Match Quality score per event. Events arriving is not the test — deduplicated, well-matched events arriving is. Compare Meta's reported purchases against your store's order count for the same window.
More on Cal.com → Meta
- Cal.com + Meta CAPIMeta Conversions API setup for Cal.com
- Cal.com → Google AdsConnecting Cal.com to Google Ads
- Cal.com → GA4Connecting Cal.com to GA4
RELATED GUIDES
Where Cal.com → Meta fits in the rest of your tracking
- Meta · Healthcare clinicsMeta Ads conversion tracking for healthcare clinics
- Meta · Coaches & consultantsMeta Ads conversion tracking for coaches and consultants
- Meta × Appointment SystemHow to reconcile Meta Ads against your practice or scheduling system
- Meta · Booked call → closed wonHow to track booked call to closed won for Meta Ads
- TidyCal → MetaConnecting TidyCal to Meta Conversions API
- Cal.com → X AdsConnecting Cal.com to X Ads
- Coaches & consultantsConversion tracking for coaches and consultants, where every booked call counts
- Acuity → MetaConnecting Acuity Scheduling to Meta Conversions API
Free · 30 min
Get Cal.com and Meta joined properly
WhatsAppFree30 minutesNo obligation
