Cal.com writes your client's name into the title
Cal.com builds the title of every booking itself, by stitching together the event type, the host's name and the name of the person who booked. Open any booking in your account and the title reads exactly like that.
So the title is the field that looks most harmless on a booking, and it holds a third party's name. A connector that reuses it because it is the natural name of a meeting writes your client's name to disk, without anybody having decided so.
The Cal.com connector never reuses it. The name it writes is the event type, chosen by the host and identical across every booking of the same slot. When that type cannot be read, the name stays generic.
Nor does the title count as a reason to write. A booking with no event type and no location carries no useful knowledge, so it does not come in, even when its title is nicely filled.
The closed list of fields written
What gets rendered from a booking depends on this list rather than on what the response holds. A field missing from the left-hand column is not read.
The last line surprises people, because a meeting address looks like company information. On a Cal.com booking, that field can just as easily carry the address of the person who booked, and nothing tells the two apart at write time. So the connector drops both.
The response holds the attendees, your Kastel keeps only the count
Cal.com returns the attendees in the same response as the booking. At Calendly, invitee identity is read through a separate request the connector never wrote. Here the data arrives either way, so the control has to sit at write time.
The connector does not copy the response it received. It builds a note from a closed list of fields, and that list holds no attendee name, no email address, no phone number, no answer to a booking form field, and no field carrying the email address of whoever performed an action. From the attendee list, only its length is used.
That approach has a useful side effect. A response of an unusual shape yields less text, never more, because a nested field the connector cannot read is ignored rather than copied across as it stands. A field Cal.com might add in a future version therefore has no route in.
The location follows the same logic, more strictly still. The connector writes the name of the video tool, or the fact that the meeting is in person, on the phone, or online. Any free-text string entered as a location is dropped, addresses included, because an address typed into that field may be the attendee's own and nothing tells the two apart at write time.
A booking taken in a team's name is readable by nobody
Cal.com lets you share a slot in a team's name rather than a person's. That is the setting sales teams and recruiting teams pick, so it is the one producing the most bookings.
Your Kastel cannot unfold a Cal.com team into a list of people. So it refuses to guess, and a booking taken in a team's name is filed in no department until an administrator decides. Guessing would mean filing it in one member's department, showing it to people who have nothing to do with that booking, or hiding it from those who took it. The general rule is described in governing your knowledge.
Bookings held by a person follow the host. When the hosts belong to several departments, when one of them is unknown to your governance, or when a host slot cannot be attached to anybody, the booking waits as well.
One difference with the other booking tool deserves stating. At Cal.com, a booking's host can change, and so can a person's team membership. Those changes alter nothing visible on the booking, since the displayed name stays the same. Your Kastel therefore catches them on its reconciliation pass, recomputing the department of every tracked booking and moving it when the answer has changed. Between two passes, a host change stays briefly out of date.
What teams ask us before connecting Cal.com
Will an AI be able to tell me who I am meeting tomorrow?
No, not through this connector. Attendee names, email addresses and phone numbers are never written, and the title that would hold them is never reused. A plugged-in AI will know that a booking of a given type exists, at a given time, with a given host on your team, and how many people are expected.
We host Cal.com ourselves, does that change anything?
The address of the interface is a setting of your installation, so an instance you host is supported like the online service. Two rules do not move. The connection is always made over HTTPS. And an instance sitting on your private network requires an explicit authorisation from whoever installs it, never a silent exception. The access key travels in a header and never in an address, so it does not end up in a server log.
Does a cancelled booking leave your Kastel?
No. A cancellation or a rejection marks the booking as gone at the source, and the booking is kept, readable by the same people as before, until an administrator decides to erase it. A booking cancelled before it was ever read never comes in, on the other hand: a cancellation never counts as content.
What about meetings that already happened?
A past meeting is still company knowledge and it is read like any other, as is a meeting still awaiting its host's confirmation. The reading window reaches back 180 days by default and takes every future booking.
What this connector does not do
It does not read your teams' calendars. Only bookings taken through Cal.com enter your Kastel, and a meeting created directly in a calendar is the job of the Google Calendar connector.
The names look alike, and that is accepted. Since the name written is the event type, ten bookings of the same slot carry the same one. A plugged-in AI tells them apart by their time and their host, never by their subject.
The name of the event type is text your team writes. A slot named after a client, a confidential project or a medical reason comes in with that name.
Full reconciliation has a cost. Every pass rereads all the bookings in the window rather than the changes alone, because Cal.com's interface can say what changed but not what was deleted. Without that full reread, a cancellation would go unnoticed and your Kastel would keep a meeting nobody has any more.
Connectors are not what you pay for.
The pricing page says what the free core holds, where the paid plans begin, and from what size a team needs something else.
See pricing
