Cal.com Booking Intake

O Cal.com Booking Intake transforma em registros do CRM um agendamento feito no Cal.com pela landing page de um vendedor. Uma reserva nova vira um Deal (o lead) em Meeting Scheduled, ou passa para Meeting Scheduled o Deal aberto da pessoa com aquele vendedor, mais uma Interaction (a reunião) para o vendedor certo, e a pessoa é criada no Core quando ninguém tem aquele e-mail. Um reagendamento move a mesma reunião; um cancelamento ou recusa a marca como cancelada e põe o próximo contato da reunião em hoje. Um único webhook atende a conta do Cal.com de todos os vendedores.

O maintainer do CRM cuida do roteamento por vendedor e da recuperação; o maintainer do Core revisa as pessoas que o workflow cria.

Fluxo

Gerado da versão do n8n do quadro acima: cada caixa é um nó e cada seta é uma ligação no n8n. Pílulas rosa são gatilhos, hexágonos amarelos são nós If e Switch com as saídas nas setas, cilindros azuis leem (Airtable, Data Table, HTTP GET), cilindros verdes gravam, caixas roxas chamam outro workflow e setas tracejadas são saídas de erro.

flowchart TD
  subgraph g0["Receber e conferir"]
    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["Reserva nova"]
    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["Reagendamento"]
    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["Cancelamento e recusa"]
    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 -->|sim| n8
  n13 -->|não| n14
  n14 -->|sim| n9
  n14 -->|não| n6
  n9 --> n23
  n23 --> n18
  n18 -->|sim| n16
  n18 -->|não| n8
  n6 --> n20
  n20 --> n15
  n8 --> n12
  n12 --> n11
  n11 --> n25
  n25 --> n17
  n17 -->|sim| n10
  n17 -->|não| n7
  n10 --> n5
  n5 -->|sim| n30
  n5 -->|não| n3
  n3 --> n30
  n30 --> n24
  n24 --> n27
  n27 --> n19
  n19 -->|sim| n7
  n19 -->|não| n30
  n7 --> n21
  n21 --> n4
  n4 -->|sim| n28
  n4 -->|não| 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

Sistemas que ele toca

Toda chamada ao Airtable é um nó HTTP Request com uma credencial de token do Airtable; o workflow não usa o nó Airtable. As leituras filtram pelo nome do campo ({Booking UID}, {Email} no mirror do CRM, {Email*} no Core); as gravações usam IDs de campo. Renomear um desses três campos quebra as buscas sem erro: a fórmula falha e o nó não devolve nada.

Os outros sistemas só registram o workflow. Communication o lista como o canal Webhook cal-com-bookings → n8n → CRM. Systems Central tem uma linha de System para ele. O Login e o Tool Identifier que ele compara são lookups que chegam ao CRM vindos de Tooling and Access pelo mirror Tool Account.

Gatilho e assinatura

O Cal.com Webhook aceita um POST num path fixo. Ele usa o modo de resposta padrão, então o Cal.com recebe HTTP 200 assim que a requisição chega, antes de qualquer conferência ou gravação. Um 200 no log de webhooks do Cal.com só diz que o n8n recebeu a chamada.

O Sign Body calcula o HMAC-SHA256 de JSON.stringify(body) com o segredo do webhook do Cal.com. O Verify & Parse compara o resultado com o header x-cal-signature-256 e lança “Invalid Cal.com signature (x-cal-signature-256)” quando eles diferem ou o header falta. Essa execução termina em erro e não grava nada.

O Verify & Parse só segue para BOOKING_CREATED, BOOKING_RESCHEDULED, BOOKING_CANCELLED e BOOKING_REJECTED. Qualquer outro evento não devolve itens e a execução termina ali.

O que o Verify & Parse lê do payload

Reserva nova

BOOKING_CREATED passa por estes passos, nesta ordem.

1. Checagem de duplicata. O Find Duplicate procura qualquer Interaction com o mesmo Booking UID. O Resolve para a execução quando encontra uma.
2. Roteamento por vendedor. O Get Lead Sources lê Automation: Lead Source. O Resolve pega a primeira linha que está Active, cujo Tool inclui cal.com e cujo Tool Identifier ou Login é igual a uma das chaves da conta do vendedor. O Follow up Target: Person da linha vira a pessoa responsável e o Follow up Target: Company, a empresa responsável. Quando nenhuma linha bate, o fluxo segue sem vendedor.
3. Pessoa no CRM. O Find Person (CRM) procura o e-mail no mirror People do CRM. Quando acha, o fluxo vai direto para o passo 5.
4. Pessoa no Core. Sem pessoa no CRM e com e-mail, o Find Person (Core) procura em People do Core. Quando a pessoa também não está lá, o Create Person (Core) a cria com os campos de Campos gravados. Nos dois casos o fluxo então espera o mirror do CRM: Wait 1 min, Recheck Person (CRM), Sync Check. Ele sai do loop quando a pessoa aparece ou depois da décima tentativa, cerca de dez minutos. Sem e-mail, os passos 3 e 4 não acham ninguém e nada é criado no Core.
5. Deal. O Find Deals lê os Deals ligados à pessoa (o Deals (Counterparty) dela). O Prepare Deal fica com os abertos (Deal Status Open) e reaproveita o primeiro cujo Accountable (Person)* contém a pessoa roteada ou, sem vendedor roteado, o primeiro sem pessoa responsável. O Update Deal passa esse Deal para Meeting Scheduled quando o Deal Stage* é Lead, Contacted ou vazio; um estágio posterior (Meeting Scheduled, Pitched, Proposal Sent, Negotiation) é mantido. Sem correspondência, ou sem pessoa no CRM, o Create Deal cria um Deal novo em Meeting Scheduled.
6. Interaction. O Create Interaction cria a reunião, ligada a esse Deal em Deal° e à pessoa em People°, com Result Meeting booked. Nenhum Relationship é criado, e o fluxo não preenche Campaign° no Deal.

Reagendamento

BOOKING_RESCHEDULED roda o Find Original Meeting com o UID original. O Prepare Reschedule só aceita uma Interaction cujo Result é Meeting booked.

Quando acha uma, o Move Meeting atualiza essa mesma Interaction: Date*, Title*, Booking UID (agora o UID novo), Next Contact Date° e Next Action°, a Evidence URL quando o payload traz URL da reunião, e uma linha anexada a Note. O Deal não muda, nem Result e Accountable.

Quando não acha nenhuma (o original foi cancelado ou nunca chegou ao CRM), o item vai para o Find Duplicate; veja em Lacunas conhecidas o que acontece ali.

Cancelamento e recusa

BOOKING_CANCELLED e BOOKING_REJECTED rodam o Find Booked Meeting com o UID atual. O Prepare Cancellation escolhe a Interaction cujo Result é Meeting booked. Quando não há nenhuma (já cancelada, ou a reserva nunca chegou ao CRM), a execução termina sem gravar.

O Mark Meeting Cancelled põe Result em Meeting cancelled, Next Contact Date° em hoje, Next Action° em “Meeting cancelled, reach out to rebook” (“rejected” numa recusa) e anexa a Note uma linha com o motivo. É nessa Interaction que o follow-up aparece. O Deal não muda: o Deal Stage* continua em Meeting Scheduled, ou onde estava.

Campos gravados

People do Core (Create Person (Core))

Deal do CRM

O workflow não grava nada no Relationship, que foi apagado em 04/11/2026.

O Company° não é gravado; o vendedor preenche quando souber a empresa do lead.

Interaction do CRM

O Company° não é gravado. As gravações em Deal, Interaction e People do Core mandam typecast: true, então um valor de select que ainda não existe (um Result ou Deal Stage* renomeado, por exemplo) é criado como opção nova em vez de falhar.

Nós

O workflow tem 32 nós: 31 que executam e uma nota adesiva. Num nó If, a saída 0 é verdadeiro e a saída 1 é falso.

Ligações

Configurações e tratamento de erro

Não há agendamento; o workflow só roda quando o Cal.com o chama. Uma chamada ao Airtable que falha para a execução onde está, depois que as gravações anteriores já foram salvas.

Lacunas conhecidas

Estas vêm da configuração dos nós. A versão com Deal foi publicada em 04/11/2026 e testada só numa simulação local (quatro casos); nenhuma reserva real passou por ela ainda. Na versão anterior, com Relationship, três caminhos rodaram no n8n: uma reserva nova para uma pessoa existente, um reagendamento com o original encontrado e um cancelamento.

Recuperar uma gravação parcial

Veja o que foi salvo antes de reenviar uma entrega.

Manter esta página em dia

O quadro no topo mostra a versão do n8n que esta página descreve. Abra o workflow no n8n: quando o último salvamento dele é mais novo que a data do quadro, esta página está desatualizada até a próxima revisão. Todos os nós e todas as ligações dessa versão estão em Nós e Ligações.