All nodes/Integrations/Calendar

Calendar Schedule

PUT scheduling message (invite/reply/cancel) to configured outbox.

Calendar Schedule▶

CalDAV connectionOutcome

Error

Type in the graph: calendar_schedule

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

Entry

Calendar Schedule▶

CalDAV Config

Exit▶

Execute
Data
Execute + Data

Press “Copy nodes”, open the editor and hit Ctrl+V on the canvas.

Pick your own connection or knowledge base first — the graph carries REPLACE_ME.

When to use it

Sends attendees an iTIP message — an invitation, a reply to one, or a cancellation — through the server’s scheduling outbox. The node does not create the event in the calendar: run Put Calendar Event first, then this node to send the invitation out.

It does not work everywhere. Two things are needed at once: a filled-in “Outbox URL” on the CalDAV connection, and a server that implements RFC 6638 scheduling. iCloud and Google CalDAV do not, and the node refuses before the request, naming the provider; the provider is inferred from the connection’s base URL.

How it works

The message body is composed the same way as in the put node: from the fields — “Title” and “Starts at” are required — or from the “iCalendar body” field, which wins over the fields as long as it is non-empty. The METHOD property is set by the node from the chosen operation: invite → REQUEST, reply → REPLY, cancel → CANCEL.

The finished message is placed into the outbox collection. The output is { "ok": true }: it means the server accepted the message for delivery, not that attendees received it.

Common mistakes

A blank outbox URL. The node stops with a VALIDATION code. The field lives in the CalDAV integration’s settings rather than on the node — fix the connection and run again.
Expecting the event to appear in the calendar. Scheduling only sends the message. Creating the meeting is Put Calendar Event.
A reply or a cancellation with no original UID. REPLY and CANCEL address a specific meeting: put its UID into the “Event UID” field, {{ nodes.<get>.output.summary.uid }} for instance, or recipients see an unrelated message.
No organizer. Most servers require ORGANIZER on an invitation and reject a message without it. The field sits under the advanced group.
Nobody to send to. With no attendees the message goes nowhere: list the addresses in the “Attendees” field, comma- or newline-separated.

Inputs

Port	Wire	Payload	Notes
CalDAV connection`calendar_store`	Data`data`	—	required

Outputs

Port	Wire	Payload	Notes
Outcome`output`	Execute + Data`execute_data`	`object`
Error`on_error`	Execute + Data`execute_data`	—	shown when expose_error_output = true

Configuration

Field	Type	Default	Description
CalDAV connection`connection_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
Scheduling operation`operation`	`string`	`invite`	iTIP method to send: invite (REQUEST), reply (REPLY) or cancel (CANCEL). Requires a connection with a scheduling outbox URL; iCloud and Google CalDAV do not implement scheduling at all. Options: `invite` — Invite (REQUEST), `reply` — Reply (REPLY), `cancel` — Cancel (CANCEL)
Event body`body_mode`	`string`	`fields`	How the iCalendar body is produced: from the fields below, or from a raw iCalendar document. A non-empty raw body is used regardless of this setting. Options: `fields` — Build from fields, `raw` — Raw iCalendar
Title`summary`	`string`	`""`	Event title (SUMMARY). Required when building from fields. supports templates shown when «Event body» = Build from fields
Starts at`dtstart`	`string`	`""`	Start, ISO 8601 (2026-07-01T10:00:00Z), or a plain date (2026-07-01) for an all-day event. Required when building from fields. supports templates shown when «Event body» = Build from fields
Ends at`dtend`	`string`	`""`	End, ISO 8601. Empty means the server decides the duration. supports templates shown when «Event body» = Build from fields
All-day event`all_day`	`boolean`	`false`	Write DTSTART/DTEND as dates (VALUE=DATE) instead of times. shown when «Event body» = Build from fields
Location`location`	`string`	`""`	Free-form place (LOCATION), e.g. a room name or a meeting link. supports templates shown when «Event body» = Build from fields
Description`description`	`string`	`""`	Event body text (DESCRIPTION). supports templates shown when «Event body» = Build from fields
iCalendar body`ics`	`string`	`""`	Raw iCalendar document (VCALENDAR with one VEVENT). Takes precedence over the fields above whenever it is non-empty, so clear it to go back to the builder. Must carry UID and DTSTAMP — servers reject events without them. supports templates
Advanced
Time zone`timezone_id`	`string`	`""`	IANA time zone for times given without an offset, e.g. Europe/Moscow. Empty = treat such times as UTC. supports templates shown when «Event body» = Build from fields
Recurrence rule`rrule`	`string`	`""`	RFC 5545 RRULE without the property name, e.g. FREQ=WEEKLY;BYDAY=MO;COUNT=10. Empty = a single occurrence. supports templates shown when «Event body» = Build from fields
Attendees`attendees`	`string`	`""`	Email addresses, comma- or newline-separated. Written as ATTENDEE properties. supports templates shown when «Event body» = Build from fields
Organizer`organizer`	`string`	`""`	Organizer email address (ORGANIZER). Required by most servers for invitations. supports templates shown when «Event body» = Build from fields
Event UID`event_uid`	`string`	`""`	Stable identifier of the event. Empty = generate one. Reuse the UID of an existing event to update or cancel it. supports templates shown when «Event body» = Build from fields
Status`event_status`	`string`	`none`	Event STATUS. 'Not set' leaves the property out of the event. Options: `none` — Not set, `CONFIRMED` — Confirmed, `TENTATIVE` — Tentative, `CANCELLED` — Cancelled shown when «Event body» = Build from fields

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.