Skip to content

Calendly — event ​

Starts the workflow when Calendly reports a booked or cancelled event, or a no-show. The signed body lands in data.calendly.

The Calendly — event trigger starts the workflow when Calendly reports an event on the workflow's URL, in real time: a meeting booked (invitee.created), cancelled (invitee.canceled), a no-show marked or removed, a routing form submitted.

Like the other signed webhook triggers:

  • Origin is proven. Calendly signs each body (Calendly-Webhook-Signature header, t=…,v1=…, HMAC-SHA256 of <t>.<raw body>). The signature is checked against the "Webhook signing key" of the Calendly connection before anything is written, and a delivery older than three minutes is refused.
  • Sorting happens first. Only the ticked events start a run; the others are acknowledged and dropped.

The run has no triggering email: nodes that act on the triggering email (reply in the thread, Move, Flag) cannot be used after this trigger. Send still works when you choose the sending mailbox on the node.

To set it up:

  1. Add the trigger, choose the Calendly connection and the events, then publish. The URL <PUBLIC_BASE_URL>/hooks/wf/<token> is issued on the first publication and returned only once.
  2. Create the subscription on the Calendly side with that URL and a signing key of your choice: POST /webhook_subscriptions through the Calendly node (free request), with url, events, organization, scope and signing_key.
  3. Paste the same signing key into the "Webhook signing key" field of the Calendly connection.

At a glance ​

  • Type: trigger.calendly · version 1
  • Category: Triggers
  • Kind: Trigger — starts a run
  • Effect: No external effect (none) — nothing is written outside Loop & Roll; safe to replay
  • Needs a carrier email: No
  • Connection: Calendly
  • Outputs: main
The ports of “Calendly — event”: what comes in on the left, what goes out on the rightIt starts runs: no input. Outputs: main. It needs a Calendly connection.Calendly — eventtrigger.calendlyEventmainConnection: Calendly
The ports of “Calendly — event”: what comes in on the left, what goes out on the right

Connection ​

This node needs a Calendly connection.

Parameters ​

connection ​

Calendly connection — The Calendly connection to use. Create it once in Connections; its key never appears in the workflow.

  • Type: Connection (credential)
  • Required: Yes
  • Default: "" (empty)

events ​

Events — What starts this workflow. Nothing ticked = everything Calendly sends to this URL. A cancellation comes with data.calendly.payload.rescheduled true when it is a reschedule.

  • Type: Several choices (multiOptions)
  • Required: No
  • Default: ["invitee.created","invitee.canceled"]
  • Options:
    • invitee.created — Event booked
    • invitee.canceled — Event cancelled
    • invitee_no_show.created — Invitee marked as no-show
    • invitee_no_show.deleted — No-show removed
    • routing_form_submission.created — Routing form submitted

Outputs ​

  • main — Taken by every run started by a Calendly event whose signature is valid and that passed the event filter.

Data produced ​

What this node adds to the run data, and how to read it in an expression. <step> stands for the step key: the node name turned into an identifier (see Data and expressions).

  • {{ data.calendly }} — object. The JSON body of the event, exactly as Calendly sent and signed it.
  • {{ data.calendly.event }} — string. The event, e.g. invitee.created (booked) or invitee.canceled (cancelled).
  • {{ data.calendly.payload.email }} — string. The invitee's email address.
  • {{ data.calendly.payload.name }} — string. The invitee's name.
  • {{ data.calendly.payload.scheduled_event.start_time }} — string. When the meeting starts (ISO 8601, UTC).
  • {{ data.calendly.payload.rescheduled }} — boolean. On a cancellation: true when it is a reschedule (a new invitee.created follows).

Example ​

When a prospect books a visit, add it to the follow-up Table and confirm by email. The trigger ticks "Event booked". On each booking, a Table — add or update node writes {{ data.calendly.payload.email }} and {{ data.calendly.payload.scheduled_event.start_time }}, then Send writes to the invitee.

Tips ​

  • Without the signing key, nothing gets through. If the connection's key is empty or wrong, every delivery is refused with 404 and no run is created.
  • A reschedule is a cancellation plus a booking. Test {{ data.calendly.payload.rescheduled }} in a Condition to tell them apart.
  • No delivery identifier. Calendly sends none: a delivery that Calendly repeats can start a second run. Make the next steps idempotent (a Table keyed on the invitee, for example).
  • Untrusted content. The body comes from outside: treat its text as data, never as instructions for an AI node.
  • A workflow has at most one Calendly — event trigger, and only the published version receives events.

Loop & Roll — the workflow builder for email.