All nodes/Integrations/Calendar
List Calendars
List calendar collections for the connected CalDAV account.
Type in the graph: calendar_list_calendars
Exec
An error branch can be enabled (expose_error_output) to handle failures on their own path.
Ports can be split into separate execution and data handles.
Try it
Minimal working workflow
- Execute
- Data
- Execute + Data
Pick your own connection or knowledge base first — the graph carries REPLACE_ME.
When to use it
A scouting node: it shows which calendar collections the account has and, above all, their URLs, which then go into every other calendar node. Keeping it in a production graph is rarely worth it — a collection address is stable, so look it up once and paste it into the fields, or into the integration’s own “Default calendar URL”.
How it works
The node locates the account’s calendar home and lists the collections inside it. It has no settings of its own beyond the connection — everything is decided by the discovery mode set on the CalDAV integration.
In “Automatic” mode the node asks the server who the credentials belong to and where that user’s
calendars live, falling back to the standard .well-known/caldav address. If the connection says
“Explicit calendar URL”, the node does not go looking at all: it returns exactly one entry — that
URL, with an empty name.
The output carries calendars: each record has href, display_name and color (which may be
null).
Common mistakes
- One entry instead of all of them. That is not an empty account, it is the “Explicit calendar URL” discovery mode on the integration. Switch it to “Automatic” when you want the full list.
- An empty
display_name. The name is an optional property of a collection; rely onhref, not on the label. - “Could not discover current-user-principal”. A
PROVIDER_ERRORwith that text nearly always means the connection’s base URL is wrong. Fix the address, or switch to “Explicit calendar home” with the calendar home URL filled in. - The list is truncated at 500 collections. Out of reach for an ordinary account, but worth knowing.
- Calling it on every chat turn. Discovery is two or three requests to the server for an answer that almost never changes. Record the URL in the configuration instead.
Inputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Calendar storecalendar_store | Datadata | — | required |
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Successoutput | 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 graph does not need a separate CalDAV Config node. A node wired to the 'calendar_store' port wins over this field. connection: caldavoverridden by port: calendar_store |
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.