All nodes/Integrations/Calendar
Get Calendar Event
GET a single calendar resource (iCalendar).
Type in the graph: calendar_get_event
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
One address, one resource: the whole raw iCalendar and, more to the point, a fresh etag to
write against. When there are several addresses, fetch them in one request with
Calendar Multiget. Finding the addresses in the first place
is the job of Calendar Query.
How it works
The node fetches the object named by the “Event href” field. A relative path is resolved against
the connection’s base URL and an absolute one is used as is, so a value from a query result drops
straight in: {{ nodes.query.output.events[0].href }}.
The output carries href, etag, ics — the document exactly as the server returned it — and
summary, the parsed fields of the resource’s first component (VEVENT or VTODO): uid,
summary, dtstart, dtend, all_day, timezone, rrule, status, sequence and
last_modified. With no body at all, summary is null.
Common mistakes
summaryis an object, not a string. The event title lives at{{ nodes.<id>.output.summary.summary }};{{ nodes.<id>.output.summary }}hands over the whole field set.- Only the first component is parsed. For a recurring event with modified occurrences the
remaining components stay inside
ics— parse it yourself if you need them. - A missing resource is an error. A 404 stops the node with
error_codeNOT_FOUND, and retrying changes nothing: the failure is deterministic. To handle absence inside the graph, turn on “Error output” and branch on the code. - An ETag goes stale after any write. The value you get here holds until the event is next
modified; after Patch Calendar Event take the
etagfrom that node’s output. - A whole calendar cannot be exported this way. The field expects the address of a single object, not of a collection — the list of events comes from Calendar Query.
Inputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
CalDAV connectioncalendar_store | Datadata | — | required |
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Eventoutput | 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 |
Event hrefhref | string | "" | Path or absolute URL of the calendar object, exactly as returned by Calendar Query or Calendar Multiget ({{ nodes.<query>.output.events[0].href }}). A relative path is resolved against the connection's base URL. Example: /remote.php/dav/calendars/user/personal/9f1c-1234.ics 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.