> ## Documentation Index
> Fetch the complete documentation index at: https://cal.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Private notes

> Attach host-only notes to a booking that appear in the organizer's calendar and confirmation emails, but are hidden from guests.

Private notes let you send information about a booking to yourself as the host without exposing it
to the attendee. The selected delivery mode determines whether Cal.com adds a second host-only
calendar entry or creates separate host and guest versions of the booking. In both modes, the note
is included in the organizer's booking confirmation email.

Common uses:

* Prep material or talking points for a call
* Internal identifiers (CRM record IDs, deal stage, ticket links)
* Answers to booking questions surfaced back to the host
* Warnings or context about the attendee

> [!NOTE]
>
> Private notes are visible only to the host. They are never shared with the attendee, added to the guest-visible calendar event, or included in attendee emails.

## How private notes are delivered

Private notes support two calendar delivery modes. In both modes, the resolved note is included in
the organizer's booking confirmation email and excluded from attendee emails.

| Delivery mode | API value | What the host sees | What guests receive |
| - | - | - | - |
| **Additional entry for the host** | `duplicate_event` | The shared booking event plus a second host-only note entry | The provider's shared booking invitation |
| **Send separate invites to host and guests** | `separate_events` | One guest-free booking event containing the private note; assigned collective cohosts join as hosts | A separate Cal.com email and guest-safe ICS |

> [!NOTE]
>
> `separate_events` is not an additional private-note entry. It replaces the shared provider event
> with two independently synchronized versions of the booking, so the host sees one calendar entry
> instead of the two entries created by `duplicate_event`.

### Additional entry for the host (`duplicate_event`)

This is the default mode and preserves the provider's shared organizer-and-attendee event. Cal.com
also creates a host-only calendar entry whose title is formatted as
`📝 {title} [Private Note]`. Its description contains the resolved template, and it has no
attendees, location, or conferencing link.

On reschedule, Cal.com updates the host-only entry in place. The shared attendee event remains
connected through Google Calendar or Microsoft 365.

### Send separate invites to host and guests (`separate_events`)

In this mode, the host and guests have separate calendar events for the same Cal.com booking:

* The main host receives a guest-free event directly on their connected Google Calendar or
  Microsoft 365 calendar. It contains the normal meeting details and the resolved private note.
* For collective bookings, assigned cohosts are invited to that provider event and can see the
  private note. Team members who are not assigned to the booking are not invited.
* Guests receive a separate event through a Cal.com email and ICS attachment with no private note.

The host and guest events have different calendar identifiers and are synchronized by Cal.com:

* Changes made through Cal.com update the host's calendar event and deliver an updated or cancelled
  ICS to guests.
* Supported changes made directly in the host's calendar, including time, title, location, and
  cancellation changes, are reflected in the Cal.com booking and guest ICS.

For collective bookings, the calendar provider keeps the main host's event synchronized with its
assigned cohosts. Description and attendee-list changes made directly in that provider event are
not copied into the Cal.com booking or guest ICS, so host-only content cannot cross into the guest
event. Because Cal.com remains the source of truth, a later update made through Cal.com may replace
manual changes to the host event's description.

The organizer's email does not include an ICS attachment because the host event already exists on
their connected calendar. Changes guests make directly to their imported calendar event are not
synchronized back to Cal.com. This includes native **Accept**, **Tentative**, and **Decline** RSVP
choices in Google Calendar, Outlook, or another calendar application. Selecting **Decline** does
not cancel the Cal.com booking; guests should use the Cal.com reschedule and cancellation links.

> [!NOTE]
>
> Separate invites stay enabled when Cal.com attendee emails are turned off for a booking, for
> example a booking made through a platform OAuth client with emails disabled. Cal.com then does
> not email the guest invite. Subscribe to a [webhook](https://cal.com/docs/developing/guides/automation/webhooks.md)
> on version `2026-07-27` and send guests the `attendeeIcsContent` from the booking payload. If
> you do not deliver it, guests receive no calendar invite for the booking.

> [!NOTE]
>
> Separate invites may not be available for every event type or booking. If Cal.com cannot use this
> mode for a booking, it uses the **Additional entry for the host** method for that booking.

> [!TIP]
>
> You don't need private notes to give hosts and guests separate calendar events. If the event type
> has a custom host or guest [calendar invite template](https://cal.com/docs/features/calendar-invite-templates#separate-host-and-guest-events)
> and Private notes is off, eligible bookings get separate host and guest events with those
> templates and no private note. Ineligible bookings get the standard shared event, not an
> additional host entry.

## Enable private notes on an event type

**1. Open the event type**

Go to **Event Types** and open the event type you want to configure.

**2. Go to the Privacy tab**

Open the **Privacy** tab in the event type settings.

**3. Toggle Private notes on**

Enable **Private notes**. The **Delivery mode** selector and **Private note template** editor
appear below the toggle.

**4. Choose a delivery mode**

Select **Additional entry for the host** or, when available, **Send separate invites to host
and guests**.

**5. Write your template**

Enter the content you want in the private note. Use `{variables}` to interpolate booking data (see the reference below), or type static text.

**6. Save the event type**

Save your changes. The template is applied to all new bookings on this event type going forward.

## Template variables

The template supports the same `{variable}` syntax as the **Calendar event name** editor. Both title-case and `UPPER_SNAKE_CASE` variants resolve to the same value.

| Variable | Resolves to |
| - | - |
| `{Event type title}` / `{EVENT_TYPE_TITLE}` | The event type's title |
| `{Attendee name}` / `{USER}` / `{ATTENDEE}` | The primary attendee's full name (falls back to email) |
| `{ATTENDEE_FIRST_NAME}` / `{Scheduler first name}` | The attendee's first name |
| `{ATTENDEE_LAST_NAME}` / `{Scheduler last name}` | The attendee's last name (when captured in booking fields) |
| `{Organiser}` / `{HOST}` / `{ORGANIZER_NAME}` | The host's full name |
| `{Organiser first name}` / `{ORGANIZER_FIRST_NAME}` | The host's first name |
| `{Location}` / `{LOCATION}` | The resolved booking location (Cal Video, Zoom, address, etc.) |
| `{Event duration}` / `{EVENT_DURATION}` | The event length, formatted as `N mins` |
| `{<booking field name>}` | The value of any custom booking field on the event type |

Booking-field lookups are case-insensitive, so `{notes}` and `{NOTES}` both resolve the `notes` booking field. Unknown variables resolve to an empty string.

### Example template

```
Prep for {Attendee name} — {Event type title} ({Event duration})

Location: {Location}
Notes from booker: {notes}
```

For a 30-minute Cal Video booking from `Ada Lovelace` who left "Discuss Q3 pricing" in the notes field, this resolves to:

```
Prep for Ada Lovelace — Discovery call (30 mins)

Location: Cal Video
Notes from booker: Discuss Q3 pricing
```

## Configure via the API

Private notes are exposed on event types in the v2 API as three fields:

| Field | Type | Description |
| - | - | - |
| `privateNoteEnabled` | `boolean` | Enables host-only private notes for new bookings. |
| `privateNoteMode` | `"duplicate_event" \| "separate_events"` | Selects the calendar delivery mode. Defaults to `"duplicate_event"`. |
| `privateNoteTemplate` | `string` | The template body. Supports the variables listed above. |

Set all three when creating or updating an event type via `POST /v2/event-types` or `PATCH /v2/event-types/{eventTypeId}`:

```json theme={null}
{
  "privateNoteEnabled": true,
  "privateNoteMode": "separate_events",
  "privateNoteTemplate": "Meeting with {Attendee name} for {Event type title}"
}
```

Setting `"separate_events"` stores the requested event-type configuration. Cal.com checks the
requirements for each booking before creating any calendar events and uses `"duplicate_event"` for
that booking if a requirement is not met.

To turn private notes off, set `privateNoteEnabled` to `false`. Existing private-note calendar events on past bookings are left as-is; new bookings will not create one.

## Limitations

* Separate invites require a non-recurring, non-seated booking.
* Personal, round-robin, individually assigned managed event types, and team-owned collective
  event types can use separate invites. Personal, round-robin, and managed-child bookings require
  exactly one assigned host; collective bookings may include assigned cohosts.
* The main collective organizer must remain assigned during a reschedule. Replacing the hosts of an
  existing collective separate-invite booking through the API is supported: cohost-only changes
  update the host event audience and the existing guest invite, while a main-organizer change
  retires the outgoing organizer's host event, creates a new one owned by the incoming organizer,
  and sends guests a cancellation for the old invite followed by a fresh invitation from the new
  organizer. If the incoming organizer is not eligible for separate invites, the booking falls back
  to the **Additional entry for the host** behaviour.
* Changing an event type's host list affects future bookings. Existing collective provider events
  replace their cohost audience only when a supported Cal.com reschedule re-runs host selection or
  the booking's hosts are replaced through the API.
* Description and attendee-list changes made directly in the host calendar are not synchronized
  into the Cal.com booking or guest ICS.
* When a separate-invite requirement is not met, Cal.com uses the **Additional entry for the host**
  method. If the host has no writable connected calendar, Cal.com cannot create either form of
  host calendar entry.
* Guests can reschedule or cancel through their Cal.com booking links. Local changes made to an
  imported guest ICS are not synchronized back to Cal.com.
* Native guest RSVP responses made from an imported ICS are not synchronized to Cal.com, and a
  **Decline** response does not cancel the booking.
* Do not rely on private notes as a security boundary against people with direct access to the
  organizer's calendar.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.