All nodes/Integrations/Calendar
Calendar Free/Busy
REPORT free-busy-query for given calendars.
Type in the graph: calendar_freebusy
Exec
An error output can be enabled to handle failures on their own path.
Ports can be split into separate execution and data handles.
Try it
Minimal working scenario
- Execute
- Data
- Execute + Data
Pick your own connection or knowledge base first — the graph carries REPLACE_ME.
When to use it
Answers one question: which intervals are busy. No titles, no attendees, no event addresses — when the meetings themselves are wanted, use Calendar Query. The typical use is picking a free slot without looking inside somebody else’s calendar: free/busy access is often granted where reading events is not.
How it works
The node asks the server for busy time across a list of collections. Addresses go into “Calendar URLs”, comma- or newline-separated; a blank field means the connection’s default calendar. The range is required and follows the same rules as the calendar query: ISO 8601, end after start, no more than 366 days, a value without a time zone read as UTC.
The output carries busy_periods, a list of { "start": …, "end": … } pairs. The values arrive
exactly as the server sent them — in basic iCalendar form (20260701T090000Z), not ISO with
dashes. Reformat them yourself before showing them to anyone.
Common mistakes
- An empty list means two different things. “Nothing is booked in this range” and “the server returned no busy information” look identical. Try the node against a calendar with a known busy slot before building logic on it.
- An interval bound may be a duration. The format allows “start and length”, in which case
endholds something likePT1H. Parse the value instead of assuming it is a timestamp. - The node does not compute free windows. It returns what is busy; subtracting those intervals from a working day is your job — with a JavaScript Code node, for instance.
- Another person’s calendar is not always visible. Free/busy permissions are granted
separately on the server; a refusal arrives with the
ACCESS_DENIEDcode. - One request, one account. Only collections belonging to the connection on the port can be listed: another account’s calendars mean another node with another configuration.
Inputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
CalDAV connectioncalendar_store | Datadata | — | required |
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Busy periodsoutput | Execute + Dataexecute_data | object | |
Erroron_error | Execute + Dataexecute_data | — | shown when expose_error_output = true |
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
CalDAV connectionconnection_id | string | "" | Saved workspace CalDAV connection, so a simple calendar scenario does not need a separate CalDAV connection node. A node wired to the 'CalDAV connection' port wins over this field. connection: caldavoverridden by port: calendar_store |
Calendar URLscalendar_urls | string | "" | Calendar collection URLs to inspect, comma- or newline-separated. Empty = the default calendar URL of the connected CalDAV connection. supports templates |
Range starttime_start | string | "" | Start of the range, ISO 8601, inclusive. Example: 2026-07-01T00:00:00Z (a naive value is read as UTC). supports templates |
Range endtime_end | string | "" | End of the range, ISO 8601. Must be after the start; the range may not exceed 366 days. Example: 2026-07-31T23:59:59Z supports templates |
Shared fields
Every node has these three — the platform adds them, not the node author.
expose_error_output— When enabled, show an execution output to connect nodes that run if this step fails.split_ports_in— Show separate execution and data input handles instead of one combined port.split_ports_out— Show separate execution and data output handles instead of one combined port.