New · Cal.com integration in Q2 2026

Book inbound meetings in the same conversation that qualifies them.

Connect Cal.com to Dashly and your AI agent reads live availability, offers slots, and confirms the meeting inside the chat. The lead never waits for an SDR to follow up.

Book a demo See how it works

Cal.com CloudMCP-native · v1 ships Q2 2026

Dashly agent · 0.8s

Booked. You'll get an invite from Daniel in 10 seconds.

3s p95

From slot pick to confirmed booking

11 / 34

Cal.com MCP tools wired to your agent

SDR touches between qualification and booking

Two MCP calls

How the booking happens

Once a lead is qualified, the agent doesn't hand off to an SDR. It reads the calendar, offers real slots, and creates the booking. Two calls to Cal.com, both visible to your team in Dashly logs.

1getSlots

Read live availability for the right rep

The agent maps the lead to a manager (round-robin, territory, or named owner) and asks Cal.com for free slots over the next two days. Slots come back in start_utc / end_utc format and get cached for 30 seconds so a clarifying question doesn't double the API call.

≤ 2s p95. Returns 3 or more slots in the lead's timezone, ready to render in chat.

2createBooking

Confirm the meeting before the lead clicks away

When the lead picks a slot, the agent fires createBooking with the attendee details and your CRM metadata. Cal.com writes the event to the rep's calendar, sends the invite, and returns a meeting link.

≤ 3s p95. Lead sees a confirmation in the chat, rep sees the meeting in their calendar.

If the slot got taken in those 30 seconds (someone booked it from another channel), the agent refetches availability and offers new options in one turn. Cal.com returns a 409, we map it to slot_unavailable, the agent recovers without a double-booking. No silent failures.

Tool surface

What the agent can actually do

Cal.com's hosted MCP server ships 34 tools. We expose 11 of them to your agent prompts. The other 23 stay available at the connector level but never load into the model context, so the agent stays focused and the token bill stays sane.

One admin, one API key, three minutes

No engineering work for the customer. The Dashly admin pastes a Cal.com API key, maps managers to event-types, and the booking tools become available to any agent that needs them.

Paste the Cal.com API key

Dashly validates it with a GET /v2/me call before writing anything to storage. A bad key never lands in the vault, the admin sees the error inline.

cal_live_xxx

Map each rep to an event-type

For every manager you want bookable, set their Cal.com username and the event-type slug. Two fields per rep, takes a minute.

daniil · 30min-demo

Turn it on for an agent

Toggle Cal.com inside the agent's tool list. Booking, rescheduling, cancellation, and slot lookup are available immediately. No deploy, no code.

Tools → Cal.com → On

What happens to the key after that

Encrypted at rest in the Dashly secrets vault, never logged in plain text, never shown back to the admin after save.
If you revoke the key in Cal.com, the next call returns 401. Dashly disables booking for that tenant and pings the admin instead of letting agents pretend everything is fine.
Every booking call is audit-logged with the consumer agent ID and tenant. PII gets redacted before logs land in observability.

Why Cal.com first and not Calendly?

Most of the B2B SaaS customers we talked to in the pilot already standardize on Cal.com Cloud, so we shipped it first. Calendly gets the same treatment as a separate MCP server, planned right after Cal.com v1 stabilizes. The agent code on the Dashly side doesn't change when we add a new calendar provider.

What if the lead picks a slot that got booked elsewhere a second earlier?

Cal.com returns a 409 conflict on the createBooking call. We map it to a slot_unavailable error, the agent refetches availability, and offers the next valid slots in the same turn. The lead sees a quick "let me grab fresh times" message, not a broken flow. Double-bookings don't reach the rep's calendar.

Does this work with Google Calendar or Outlook directly?

Not in v1, and probably not the next step either. Cal.com already syncs with Google Calendar and Outlook on the manager's side, so the underlying calendar is the real one. Going direct to Google or Microsoft would mean rebuilding what Cal.com already gives us. We'll revisit if a customer can't move off raw Google.

What about Cal.com self-hosted?

Cloud only at launch. Self-hosted is on the roadmap and depends on a custom base-URL field plus a separate auth check. If you're running self-hosted today, tell us at the demo, we're tracking demand.

Who configures the integration on our side?

One admin. They paste a Cal.com API key, set a username and event-type slug per rep, and toggle the integration on for the agent. No code, no per-rep installation, no SDR onboarding. If your manager list is messy or event-types aren't consistent, the agent will surface that fast.

What happens if we revoke the API key mid-session?

The next call returns 401, Dashly catches it as auth_failed, disables booking for your tenant, and alerts the admin. The agent stops promising meetings and falls back to "I'll have someone reach out" instead of fabricating a confirmation.

For Cal.com customers

See it book a real meeting on your calendar in 20 minutes.

We wire your Cal.com workspace to a sandbox agent and walk through one qualifier-to-booking flow with your event-types, your reps, your timezone.

We bring the agent, you bring the Cal.com workspace
Live booking on a test event-type, not a slide deck
No CRM changes, no contract, no follow-up loop

Book a working session

Cal.com workspace

Connected

Mon · 11:00

Inbound demo · Alex Rivera

Mon · 14:30

Discovery · Priya Shah

Tue · 09:00

Pricing review · Tom Becker