Cal.com Booking Intake

Cal.com Booking Intake turns a Cal.com booking made on a seller’s landing page into CRM records. A new booking becomes a Deal (the lead) at Meeting Scheduled, or moves the person’s open Deal with that seller to Meeting Scheduled, plus an Interaction (the meeting) for the right seller, and the person is created in Core when nobody has that e-mail yet. A reschedule moves the same meeting; a cancellation or rejection marks it cancelled and sets the meeting’s next contact to today. One webhook serves every seller’s Cal.com account.

The CRM maintainer owns the seller routing and recovery; the Core maintainer reviews the people it creates.

Flow

Generated from the n8n version in the box above: every box is a node and every arrow is a connection in n8n. Pink pills are triggers, yellow hexagons are If and Switch nodes with their outputs on the arrows, blue cylinders read (Airtable, Data Table, HTTP GET), green cylinders write, purple boxes call another workflow, and dashed arrows are error outputs.

flowchart TD
  subgraph g0["Receive and verify"]
    n0(["Cal.com Webhook"]):::trigger
    n26["Sign Body"]:::logic
    n29["Verify & Parse"]:::logic
    n13{{"Is New Booking?"}}:::decision
    n14{{"Is Reschedule?"}}:::decision
  end
  subgraph g1["New booking"]
    n8[("Find Duplicate<br/><small>GET CRM Interaction</small>")]:::read
    n12[("Get Lead Sources<br/><small>GET CRM Lead Source</small>")]:::read
    n11[("Find Person (CRM)<br/><small>GET CRM People</small>")]:::read
    n25["Resolve"]:::logic
    n17{{"Needs Core?"}}:::decision
    n10[("Find Person (Core)<br/><small>GET Core People</small>")]:::read
    n5{{"Exists in Core?"}}:::decision
    n3[("Create Person (Core)<br/><small>POST Core People</small>")]:::write
    n30["Wait 1 min"]:::wait
    n24[("Recheck Person (CRM)<br/><small>GET CRM People</small>")]:::read
    n27["Sync Check"]:::logic
    n19{{"Person Ready?"}}:::decision
    n7[("Find Deals<br/><small>GET CRM Deal</small>")]:::read
    n21["Prepare Deal"]:::logic
    n4{{"Existing Deal?"}}:::decision
    n28[("Update Deal<br/><small>PATCH CRM Deal</small>")]:::write
    n1[("Create Deal<br/><small>POST CRM Deal</small>")]:::write
    n22["Prepare Interaction"]:::logic
    n2[("Create Interaction<br/><small>POST CRM Interaction</small>")]:::write
  end
  subgraph g2["Reschedule"]
    n9[("Find Original Meeting<br/><small>GET CRM Interaction</small>")]:::read
    n23["Prepare Reschedule"]:::logic
    n18{{"Original Found?"}}:::decision
    n16[("Move Meeting<br/><small>PATCH CRM Interaction</small>")]:::write
  end
  subgraph g3["Cancellation and rejection"]
    n6[("Find Booked Meeting<br/><small>GET CRM Interaction</small>")]:::read
    n20["Prepare Cancellation"]:::logic
    n15[("Mark Meeting Cancelled<br/><small>PATCH CRM Interaction</small>")]:::write
  end
  n0 --> n26
  n26 --> n29
  n29 --> n13
  n13 -->|true| n8
  n13 -->|false| n14
  n14 -->|true| n9
  n14 -->|false| n6
  n9 --> n23
  n23 --> n18
  n18 -->|true| n16
  n18 -->|false| n8
  n6 --> n20
  n20 --> n15
  n8 --> n12
  n12 --> n11
  n11 --> n25
  n25 --> n17
  n17 -->|true| n10
  n17 -->|false| n7
  n10 --> n5
  n5 -->|true| n30
  n5 -->|false| n3
  n3 --> n30
  n30 --> n24
  n24 --> n27
  n27 --> n19
  n19 -->|true| n7
  n19 -->|false| n30
  n7 --> n21
  n21 --> n4
  n4 -->|true| n28
  n4 -->|false| n1
  n1 --> n22
  n22 --> n2
  n28 --> n22
  classDef trigger fill:#fde7f3,stroke:#d6409f,color:#111
  classDef decision fill:#fff7e0,stroke:#c99a00,color:#111
  classDef read fill:#e8f1ff,stroke:#3b82f6,color:#111
  classDef write fill:#e7f8ee,stroke:#16a34a,color:#111
  classDef subflow fill:#f3e8ff,stroke:#9333ea,color:#111
  classDef wait fill:#f1f1f1,stroke:#888,color:#111
  classDef logic fill:#ffffff,stroke:#999,color:#111

Systems it touches

Every Airtable call is an HTTP Request node with one Airtable token credential; the workflow uses no Airtable node. Reads filter by field name ({Booking UID}, {Email} in the CRM mirror, {Email*} in Core); writes use field IDs. Renaming one of those three fields breaks the lookups without any error: the formula fails and the node returns nothing.

Other systems only register the workflow. Communication lists it as the Webhook channel cal-com-bookings → n8n → CRM. Systems Central has a System row for it. The Login and Tool Identifier it matches on are lookups that reach the CRM from Tooling and Access through the Tool Account mirror.

Trigger and signature

Cal.com Webhook accepts a POST on a fixed path. It uses the default response mode, so Cal.com gets HTTP 200 as soon as the request arrives, before any check or write. A 200 in Cal.com’s webhook log only says that n8n received the call.

Sign Body computes HMAC-SHA256 over JSON.stringify(body) with the Cal.com webhook secret. Verify & Parse compares the result with the x-cal-signature-256 header and throws “Invalid Cal.com signature (x-cal-signature-256)” when they differ or the header is missing. That execution ends in error and writes nothing.

Verify & Parse continues only for BOOKING_CREATED, BOOKING_RESCHEDULED, BOOKING_CANCELLED and BOOKING_REJECTED. Any other event returns no items and the execution ends there.

What Verify & Parse reads from the payload

New booking

BOOKING_CREATED goes through these steps in order.

1. Duplicate check. Find Duplicate looks for any Interaction with the same Booking UID. Resolve stops the execution when one exists.
2. Seller routing. Get Lead Sources reads Automation: Lead Source. Resolve takes the first row that is Active, whose Tool includes cal.com, and whose Tool Identifier or Login equals one of the seller account keys. The row’s Follow up Target: Person becomes the accountable person and Follow up Target: Company the accountable company. When no row matches, the flow continues without a seller.
3. Person in the CRM. Find Person (CRM) looks for the e-mail in the CRM People mirror. When it is found, the flow goes straight to step 5.
4. Person in Core. With no CRM person and an e-mail present, Find Person (Core) searches Core People. When the person is not there either, Create Person (Core) adds them with the fields under Fields written. Either way the flow then waits for the CRM mirror: Wait 1 min, Recheck Person (CRM), Sync Check. It leaves the loop when the person appears or after the tenth attempt, about ten minutes. Without an e-mail, steps 3 and 4 find nobody and nothing is created in Core.
5. Deal. Find Deals reads the Deals linked to the person (their Deals (Counterparty)). Prepare Deal keeps the open ones (Deal Status Open) and reuses the first whose Accountable (Person)* contains the routed person, or, with no seller routed, the first one with no accountable person. Update Deal moves that Deal to Meeting Scheduled when its Deal Stage* is Lead, Contacted or empty; a later stage (Meeting Scheduled, Pitched, Proposal Sent, Negotiation) is kept. Without a match, or without a CRM person, Create Deal adds a new Deal at Meeting Scheduled.
6. Interaction. Create Interaction adds the meeting, linked to that Deal in Deal° and to the person in People°, with Result Meeting booked. No Relationship is created, and the flow does not set Campaign° on the Deal.

Reschedule

BOOKING_RESCHEDULED runs Find Original Meeting with the original UID. Prepare Reschedule keeps only an Interaction whose Result is Meeting booked.

When it finds one, Move Meeting updates that same Interaction: Date*, Title*, Booking UID (now the new UID), Next Contact Date° and Next Action°, the Evidence URL when the payload has a meeting URL, and a line appended to Note. The Deal does not change, and neither do Result and Accountable.

When it finds none (the original was cancelled or never reached the CRM), the item goes to Find Duplicate; see Known gaps for what happens there.

Cancellation and rejection

BOOKING_CANCELLED and BOOKING_REJECTED run Find Booked Meeting with the current UID. Prepare Cancellation picks the Interaction whose Result is Meeting booked. When there is none (already cancelled, or the booking never reached the CRM) the execution ends without writing.

Mark Meeting Cancelled sets Result to Meeting cancelled, Next Contact Date° to today, Next Action° to “Meeting cancelled, reach out to rebook” (“rejected” for a rejection) and appends a line with the reason to Note. That Interaction is where the follow-up shows. The Deal does not change: its Deal Stage* stays at Meeting Scheduled, or wherever it was.

Fields written

Core People (Create Person (Core))

CRM Deal

The workflow writes nothing to Relationship, which was deleted on 2026-11-04.

Company° is not written; the seller fills it when the lead’s company is known.

CRM Interaction

Company° is not written. Writes to Deal, Interaction and Core People send typecast: true, so a select value that does not exist yet (a renamed Result or Deal Stage*, for example) is created as a new option instead of failing.

Nodes

The workflow has 32 nodes: 31 that run and one sticky note. For an If node, output 0 is true and output 1 is false.

Connections

Settings and error handling

There is no schedule; the workflow runs only when Cal.com calls it. A failed Airtable call stops the execution where it is, after any earlier writes have already been saved.

Known gaps

These come from the node configuration. The Deal version was published on 2026-11-04 and tested only in a local simulation (four cases); no real booking has run through it yet. With the earlier Relationship version, three paths ran in n8n: a new booking for an existing person, a reschedule with the original found, and a cancellation.

Recover a partial write

Look at what was saved before you replay a delivery.

Keep this page in sync

The box at the top shows the n8n version this page describes. Open the workflow in n8n: when its last save is newer than the date in the box, this page is out of date until the next review. Every node and every connection of that version is listed in Nodes and Connections.