Resources · n8n integration

Cal.com n8n integrationAutomate Cal.com with n8n.

Wondering what the Cal.com n8n integration actually covers? It listens, and that is all it does. One node ships with n8n, the Cal.com Trigger, and it receives 4 webhook events spread over 4 booking families. Anything you want to write back into Cal.com goes through the HTTP Request node.

Try the Cal.com integration on n8n

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the Cal.com n8n integration actually do?

The Cal.com n8n integration runs one way. n8n ships a single Cal.com node, the Cal.com Trigger, and its job is to sit and wait. Cal.com calls an n8n URL every time something happens to a booking, and the workflow starts with that booking payload already loaded. There is no Cal.com action node in the catalog, so n8n reads your calendar events and writes nothing back through a dedicated node.

The first pattern is the welcome pack. A prospect picks a slot, BOOKING_CREATED fires, and the workflow logs the attendee, the event type and the start time as a row in Google Sheets before pinging the account owner. The sales rep opens the call already knowing who booked and from which page.

The second pattern is damage control on cancellations. BOOKING_CANCELLED lands, the workflow drops a short message in the right channel through Slack, and marks the slot as freed in your tracker. For a team selling demos, a cancellation that nobody sees for two days is a lost week.

The third pattern starts once the call is over. MEETING_ENDED is the cue for follow-up: draft the recap with Openai, then send it from the rep's own inbox with Gmail. Same day, every time, without anyone remembering to do it.

Where the trigger stops, HTTP Request takes over. Nothing on the Cal.com side runs through a dedicated action node here, because the catalog lists 0 operations for this tool. The HTTP Request node calls any Cal.com API endpoint and reuses the same credential through predefined authentication, so you stay on one set of keys.

Two limits worth knowing before you plan a build. The trigger has no wildcard option, so every event you want has to be checked in the Events list one by one. And the payload is whatever Cal.com sends: if a field you need is missing, the Payload Template option is where you shape it. If you are still choosing a platform, the n8n review goes through the trade-offs in detail.

Connect

How do you connect Cal.com to n8n?

  1. 01

    Generate an API key in Cal.com

    You need a Cal.com account first. From there, generate an API key, which is the string Cal.com uses to recognize the calls coming from n8n. Cal.com documents where new keys are created and how they are scoped, and the trigger supports exactly one authentication method: API key. Copy the key once, because most tools show it a single time.

  2. 02

    Create the credential in n8n

    In the Credentials menu, create a Cal.com credential. It asks for two things. API Key takes the string you just generated. Host takes https://api.cal.com if you are on the cloud version of Cal.com, or the address of your own instance if you self-host. A credential is created once and reused by every workflow that needs it.

  3. 03

    Add the trigger and activate the workflow

    Drop the Cal.com Trigger on the canvas, pick the credential from the dropdown, then check the events you care about under Events. Activating the workflow is what registers the webhook, meaning the URL Cal.com will call. A webhook is just that: an address the tool hits the moment something happens, instead of n8n asking over and over.

Triggers

What can the Cal.com Trigger listen to?

Cal.com Trigger is the node that starts a workflow when something happens in Cal.com. It listens to 4 events, listed below by family. Pick one or several, activate the workflow: n8n registers the webhook on your Cal.com account.

What you see in n8n

Every event, by family

One row per object, one chip per action. The event to tick in the node is object.action; hover a chip to read exactly when it fires.

BOOKING_CANCELLED.*1
  • BOOKING_CANCELLED.
    • BOOKING_CANCELLED
BOOKING_CREATED.*1
  • BOOKING_CREATED.
    • BOOKING_CREATED
BOOKING_RESCHEDULED.*1
  • BOOKING_RESCHEDULED.
    • BOOKING_RESCHEDULED
MEETING_ENDED.*1
  • MEETING_ENDED.
    • MEETING_ENDED

Configuration notes

01Configure the Cal.com TriggerOne node covers the whole integration, and its setup is short. You pick the events, n8n registers the webhook with Cal.com when the workflow goes live, and each notification arrives within seconds of the booking changing. The node runs on version 2, with options that let you narrow what comes through.

One node covers the whole integration, and its setup is short. You pick the events, n8n registers the webhook with Cal.com when the workflow goes live, and each notification arrives within seconds of the booking changing. The node runs on version 2, with options that let you narrow what comes through.

Key parameters

  • Events: the list of notifications to subscribe to. There is no catch-all value here, so check each of the 4 events you actually want.
  • API Version: which Cal.com API version the trigger talks to, useful when your instance is behind the cloud.
  • App ID: limits the workflow to bookings coming from one app instead of the whole account.
  • EventType Name or ID: picks a single event type to monitor, from the list or through an expression such as {{ $json.eventTypeId }}.
  • Payload Template: reshapes the body Cal.com sends, when the default structure does not match what the next node expects.
Use cases
a single workflow that reacts to every booking on the account, or four narrow workflows that each watch one event type and one app.
02Booking CreatedSomeone picked a slot. BOOKING_CREATED fires as soon as the booking is confirmed on the Cal.com side, and the payload carries the meeting that was just added to the calendar. This is the busiest of the 4 events on most accounts, since it covers every new reservation regardless of who made it.

Someone picked a slot. BOOKING_CREATED fires as soon as the booking is confirmed on the Cal.com side, and the payload carries the meeting that was just added to the calendar. This is the busiest of the 4 events on most accounts, since it covers every new reservation regardless of who made it.

Key parameters

  • Events: check Booking Created and leave the rest unticked if creation is all you care about.
  • EventType Name or ID: keeps the workflow on one event type, so a demo booking does not run the onboarding branch.
When to use it
whenever the first minute after a booking matters, which is most of the time in sales and support.
Use cases
enrich the attendee before the call, open a ticket for the assigned owner, or log the reservation in the pipeline sheet.
03Booking RescheduledA meeting moved. BOOKING_RESCHEDULED covers the case where an existing booking changes slot rather than disappearing, which matters because a reschedule is not a cancellation followed by a creation. Treating it as one duplicates reminders and confuses whatever you built downstream.

A meeting moved. BOOKING_RESCHEDULED covers the case where an existing booking changes slot rather than disappearing, which matters because a reschedule is not a cancellation followed by a creation. Treating it as one duplicates reminders and confuses whatever you built downstream.

Key parameters

  • Events: check Booking Rescheduled to receive the new slot for a meeting that already existed.
  • Payload Template: shapes the body so the next node gets the fields it needs in the structure it expects.
When to use it
any workflow that already wrote the meeting somewhere and now has to keep that copy honest.
Use cases
update the row you created earlier instead of adding a second one, and cancel the reminder that pointed at the old time.
04Booking CancelledThe slot is free again. BOOKING_CANCELLED arrives when a Cal.com event is cancelled, and it is the event teams notice last, because nothing shows up on a calendar to remind them. A workflow that catches it turns a silent hole in the day into an alert someone can act on.

The slot is free again. BOOKING_CANCELLED arrives when a Cal.com event is cancelled, and it is the event teams notice last, because nothing shows up on a calendar to remind them. A workflow that catches it turns a silent hole in the day into an alert someone can act on.

Key parameters

  • Events: check Booking Cancelled on its own for an alerting workflow, or alongside Booking Created for a full audit trail.
  • App ID: narrows the subscription to bookings from one app, handy when several tools write into the same account.
When to use it
when an empty slot has a cost, whether that is a rep sitting idle or a paid consultation.
Use cases
alert the owner, reopen the lead in the CRM, and send the prospect a link to pick another time.
05Meeting EndedThe call is over. MEETING_ENDED fires once a Cal.com event or meeting has finished, which makes it the only one of the 4 events that is about what happened rather than what was planned. Everything that belongs after a conversation hangs off this one.

The call is over. MEETING_ENDED fires once a Cal.com event or meeting has finished, which makes it the only one of the 4 events that is about what happened rather than what was planned. Everything that belongs after a conversation hangs off this one.

Key parameters

  • Events: check Meeting Ended to start the workflow at the end of the call rather than at booking time.
  • API Version: pins which Cal.com API version the trigger uses, worth setting when a self-hosted instance lags behind.
When to use it
for follow-up work that would be wrong to send before the meeting has actually taken place.
Use cases
send the recap email, ask for feedback, or move the deal to the next stage without waiting for anyone to remember.
Need help

Need help automating Cal.com with n8n?

A person reads every message.

FAQ

Cal.com and n8n, the questions that come next

01Is the Cal.com n8n integration free?
Yes on the n8n side. The Cal.com Trigger ships with n8n, so there is nothing to install and nothing extra to pay for the node itself. That holds on n8n Cloud, the hosted offer run by n8n, and on a self-hosted instance under the Community Edition and its Sustainable Use license. A workflow built in one place behaves the same in the other. What a Cal.com account costs is a separate question and depends on your plan there, which this page does not cover. The only technical requirement is an API key from an existing Cal.com account.
02What credentials does the Cal.com Trigger need?
One credential with two fields. Cal.com supports a single authentication method here, the API key, so you generate a key in your Cal.com account and paste it into the API Key field of the credential. The second field is Host. Leave it at https://api.cal.com when you use the cloud version of Cal.com, or enter the address of your own instance when you self-host. Once saved, that credential lives in the n8n Credentials menu and every workflow that uses the trigger picks it from a dropdown, so you enter the key once rather than per workflow.
03What are the limits of Cal.com in n8n?
The big one: there is no Cal.com action node. The catalog lists 0 operations for this tool, so nothing runs through a dedicated node on the Cal.com side. Use the HTTP Request node for that, pointing it at any Cal.com API endpoint and reusing the same credential through predefined authentication. The trigger itself has no wildcard value either, so every event you want has to be ticked explicitly in the Events list. And you receive the payload Cal.com decides to send, with the Payload Template option as the way to reshape it.
04Does the Cal.com Trigger work in real time?
Yes. This trigger runs on webhooks, which means Cal.com calls an n8n URL the moment something happens instead of n8n asking at intervals. n8n registers that URL with Cal.com when you activate the workflow, and each event then lands within seconds. No polling, no schedule to tune, no delay to explain to the person waiting on the alert. One consequence is worth remembering: a workflow that is not active has no registered webhook, so events that occur while it is switched off are not queued up for later.
05n8n or Make for Cal.com?
It depends on what you optimize for. Make is a hosted platform with no self-hosting option and billing per operation, so the cost follows your volume and the data goes through their infrastructure. n8n can be self-hosted with Docker or npm, or used on n8n Cloud, and the same workflow behaves identically either way, which matters when meeting data has to stay on your own servers. On the Cal.com side, both go through webhooks, and both need the HTTP Request equivalent for anything beyond listening, since no action node exists. Judge on hosting, data control, cost model and how comfortable your team is with the visual logic.
Same platform

Other docs you might need on this stack.

Browse all integrations