Cal.com vs SavvyCal

Agent ops

1. ai-native userMy agent can check availability, book, reschedule, and cancel meetings end to end through the API or MCP — no dashboard needed

   weight 3 · round to Cal.com
   Cal.com✓fullprobed8/10

   Cal.com's API v2 and hosted MCP server are explicitly documented as enabling AI agents to check availability, create, and reschedule bookings without a dashboard, with public booking endpoints for agent use and natural-language management via any MCP client (cal-com-docs-11,12,17,18,30,45,46,50, probe-4). Cancellation is only implied via the BOOKING_CANCELLED webhook trigger and reschedule-status docs rather than an explicitly cited cancel-booking endpoint, and there is no independent/hands-on corroboration of the full agent workflow. Missing for 10: explicit docs/citation of a dedicated cancel-booking API call, and third-party validation of end-to-end agent use.

   • [claimed-docs] “Connect AI clients to Cal.com scheduling through the Model Context Protocol using the hosted server at mcp.cal.com or a local instance.”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: **Check availability** - Query available time slots for any user or team * **Create bookings** - Schedu…”
   • [claimed-docs] “Query available slots using username and event slug—no need to look up IDs first”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client”
   • [claimed-docs] “For agents that can execute commands on a machine, use the official Cal.com CLI instead of calling the API directly.”
   • [claimed-docs] “The booking creation endpoint is public and does not require authentication. This allows agents to book on behalf of external users.”
   • [claimed-docs] “There are 4 ways to get available slots for event type of an individual user: 1. By event type id.”
   • [claimed-docs] “Reschedule a booking or seated booking.”
   • [claimed-docs] “Reschedule a booking or seated booking. Reschedulable booking statuses: - `accepted` — the confirmed booking is moved to the new start time.…”
   • [probe] “official MCP server documented at https://cal.com/docs/mcp-server”

   proof ↗⚑ flag

   SavvyCal~partialprobed3/10

   SavvyCal has a documented REST API with OAuth/PAT auth and a named 'Meetings API' (savvycal-docs-5,45,50,53,54,61), suggesting programmatic meeting management exists, but there is no evidence of specific endpoints for checking availability, booking, rescheduling, or canceling meetings, and no MCP server is mentioned anywhere. Probes confirm no discoverable OpenAPI spec or llms.txt, undermining agent-readiness. missing for 10: explicit API endpoints/docs for availability check, book, reschedule, cancel; any MCP server or agent-specific integration; independent confirmation of end-to-end API scheduling flow.

   • [claimed-docs] “OAuth 2.0: OAuth2 ... HTTP: Bearer Auth ... Personal access token authentication”
   • [claimed-docs] “Personal access token authentication”
   • [claimed-docs] “OAuth 2.0 authorization code flow ... Personal access token authentication”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”
   • [claimed-docs] “OAuth 2.0: OAuth2 ... Personal access token authentication ... Bearer format: pt_secret_XXXXXXXXX”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.savvycal.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

2. ai-native userAgents can use my scheduling account as a tool — an MCP server or tool-calling surface exposes availability, bookings, and event types

   weight 2 · round to Cal.com
   Cal.com✓fullprobed8/10

   Cal.com documents a hosted/local MCP server (mcp.cal.com) that lets AI clients manage bookings, event types, and schedules via natural language, plus a dedicated agents.md guide describing API v2 endpoints for checking availability, creating bookings, and managing event types, corroborated by a probe confirming the MCP server doc page. missing for 10: independent/hands-on third-party confirmation that the MCP server works reliably in practice, and no evidence of a full tool-calling schema/manifest beyond docs.

   • [claimed-docs] “Connect AI clients to Cal.com scheduling through the Model Context Protocol using the hosted server at mcp.cal.com or a local instance.”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client.”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: **Check availability** - Query available time slots for any user or team * **Create bookings** - Schedu…”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: **Check availability** - Query available time slots for any user or team * **Create bookings** - Schedu…”
   • [claimed-docs] “For agents that can execute commands on a machine, use the official Cal.com CLI instead of calling the API directly.”
   • [claimed-docs] “The booking creation endpoint is public and does not require authentication. This allows agents to book on behalf of external users.”
   • [probe] “official MCP server documented at https://cal.com/docs/mcp-server”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal offers a REST API, webhooks, and OAuth/PAT auth, but there is no evidence of an MCP server, tool-calling schema, or agent-facing surface; probes for llms.txt and OpenAPI spec both 404, indicating no discoverable machine/agent tool interface.

   • [claimed-docs] “The SavvyCal API adheres to REST conventions. Our API communicates in JSON format and uses OAuth access tokens to authenticate requests.”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.savvycal.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Cal.com
   Cal.com✓fullprobed9/10

   Cal.com has a verified llms.txt (HTTP 200 probe) plus a dedicated agent-oriented docs page (cal.com/docs/agents.md) explicitly describing how AI agents should use the API, and a documentation index directive pointing agents to the full llms.txt for discovery. missing for 10: independent third-party confirmation that an agent successfully navigated the docs end-to-end via llms.txt.

   • [probe] “PROBE llms.txt: HTTP 200 at https://cal.com/llms.txt # Cal.com: Scheduling Infrastructure for Individuals, Teams, and Organizations > C…”
   • [claimed-docs] “Share a booking link, connect your calendars, and let people pick a time without the back-and-forth.”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “For agents that can execute commands on a machine, use the official Cal.com CLI instead of calling the API directly.”
   • [claimed-docs] “\> ## Documentation Index > Fetch the complete documentation index at: https://cal.com/docs/llms.txt > Use this file to discover all availab…”
   • [probe] “PROBE docs-md: HTTP 200 at https://cal.com/docs/api-reference/v2/introduction.md > ## Documentation Index > Fetch the complete documentation…”

   proof ↗⚑ flag

   SavvyCal—none0/10

   A direct probe for llms.txt returned a 404, and no evidence indicates any agent-oriented documentation or AI-consumable docs format exists.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.savvycal.com/llms.txt”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Cal.com
   Cal.com~partialcommunity6/10

   Cal.com exposes a full REST API v2 (OAuth/API key auth, bookings, event types, schedules, webhooks) plus a documented CLI recommendation for agents that execute commands, enabling headless/CI automation of scheduling workflows. However, evidence is entirely first-party docs with no independent/hands-on confirmation of running it in CI pipelines, no CI-specific examples (e.g., GitHub Actions), and self-hosting/community reports raise friction concerns (broken docker builds, API not self-hostable) that could affect headless deployment reliability. missing for 10: independent CI/automation case study or hands-on verification, explicit CI pipeline examples, and confirmation that self-hosted headless API deployment works smoothly given community-reported self-hosting friction.

   • [claimed-docs] “The Cal.com API has 3 authentication methods: 1. OAuth 2. API key 3. Platform (Deprecated)”
   • [claimed-docs] “Authentication to the API is performed via the Authorization header.”
   • [claimed-docs] “For agents that can execute commands on a machine, use the official Cal.com CLI instead of calling the API directly.”
   • [claimed-docs] “The booking creation endpoint is public and does not require authentication. This allows agents to book on behalf of external users.”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [community] “the problem with cal.com 'open source' self-hosting is that they have made it quite difficult to run yourself... this actually doesn't provi…”
   • [community] “Also the docker compose in the repo is a mess and doesn't work... Clearly it seems to be a way to limit usage of the selfhosted version.”

   proof ↗⚑ flag

   SavvyCal~partialclaimed4/10

   SavvyCal exposes a REST API with OAuth/personal-access-token auth and webhooks (savvycal-docs-1, savvycal-docs-5, savvycal-docs-45) which allows scripted, non-UI automation of scheduling tasks, giving a partial headless-usage path. However there is no CLI, no documented CI/automation runner, and no explicit guidance for unattended CI execution. Missing for 10: a CLI or headless mode, CI-specific documentation/examples, and evidence of unattended/automated execution outside interactive OAuth flows.

   • [claimed-docs] “The SavvyCal API adheres to REST conventions. Our API communicates in JSON format and uses OAuth access tokens to authenticate requests.”
   • [claimed-docs] “OAuth 2.0: OAuth2 ... HTTP: Bearer Auth ... Personal access token authentication”
   • [claimed-docs] “Personal access token authentication”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Cal.com
   Cal.com✓fullprobed8/10

   Cal.com documents an official hosted MCP server (mcp.cal.com) plus a local instance option, explicitly letting AI clients manage bookings, event types, and schedules via natural language in any MCP-compatible client, corroborated by a probe confirming the docs page exists. missing for 10: independent hands-on community verification that the MCP server works reliably in practice.

   • [claimed-docs] “Connect AI clients to Cal.com scheduling through the Model Context Protocol using the hosted server at mcp.cal.com or a local instance.”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client.”
   • [probe] “official MCP server documented at https://cal.com/docs/mcp-server”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal is a scheduling SaaS, so publishing an official MCP server is a fair, applicable question for its ecosystem, but there is no mention of MCP anywhere in the evidence—only REST API, webhooks, and JS embed integrations are documented. missing for 10: any mention of an MCP server, agent integration, or MCP protocol support.

   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.savvycal.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Cal.com
   Cal.com~partialclaimed4/10

   Cal.com's docs explicitly mention an official CLI for agentic/automation use ('use the official Cal.com CLI instead of calling the API directly'), confirming the capability exists, but the evidence pack contains no further detail on installation, command set, or independent verification. Missing for 10: CLI documentation/README, install instructions, command reference, and any hands-on or community confirmation of the CLI in use.

   • [claimed-docs] “For agents that can execute commands on a machine, use the official Cal.com CLI instead of calling the API directly.”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal offers a REST API, webhooks, and JS embed library, but there is no mention anywhere of an official CLI tool for AI-native workflows.

   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Cal.com
   Cal.com✓fullprobed8/10

   Cal.com ships a comprehensive, well-documented public API v2 covering bookings, event types, schedules, webhooks, slots, and routing traces, with clear auth methods (OAuth, API key) and dedicated docs pages for AI agents/MCP usage. Community evidence corroborates self-hosting the API is possible, though probes found no discoverable OpenAPI spec file at standard paths. Missing for 10: a verifiable machine-readable OpenAPI/Swagger spec (probe found 404s at standard paths), and independent hands-on developer confirmation of the API's real-world reliability beyond vendor docs.

   • [claimed-docs] “The Cal.com API has 3 authentication methods: 1. OAuth 2. API key 3. Platform (Deprecated)”
   • [claimed-docs] “You can view and manage your API keys in your settings page under the security tab in Cal.com.”
   • [claimed-docs] “Authentication to the API is performed via the Authorization header.”
   • [claimed-docs] “Provide `eventTypeSlug` and `username` and optionally `organizationSlug` if the user with the username is within an organization.”
   • [claimed-docs] “Reschedule a booking or seated booking.”
   • [claimed-docs] “Create a schedule for the authenticated user. The point of creating schedules is for event types to be available at specific times.”
   • [claimed-docs] “BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING_REQUESTED - BOOKING_CANCELLED”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “The booking creation endpoint is public and does not require authentication. This allows agents to book on behalf of external users.”
   • [community] “I self host it, and I self host both the API and the database.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://cal.com/openapi.json, https://cal.com/swagger.json, https://cal.com/api/openapi.json, https:…”
   • [probe] “PROBE docs-md: HTTP 200 at https://cal.com/docs/api-reference/v2/introduction.md > ## Documentation Index > Fetch the complete documentation…”

   proof ↗⚑ flag

   SavvyCal✓fullprobed7/10

   SavvyCal documents a public REST API using JSON, OAuth2 and personal access tokens, plus webhooks with HMAC signing and a JS embed library, giving programmatic/agentic control over scheduling. Missing for 10: a discoverable machine-readable OpenAPI spec or llms.txt (probes returned 404) and independent/hands-on corroboration of API completeness.

   • [claimed-docs] “The SavvyCal API adheres to REST conventions. Our API communicates in JSON format and uses OAuth access tokens to authenticate requests.”
   • [claimed-docs] “OAuth 2.0: OAuth2 ... HTTP: Bearer Auth ... Personal access token authentication”
   • [claimed-docs] “Our API communicates in JSON format and uses OAuth access tokens to authenticate requests.”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”
   • [claimed-docs] “OAuth 2.0: OAuth2 ... Personal access token authentication ... Bearer format: pt_secret_XXXXXXXXX”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.savvycal.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Cal.com
   Cal.com~partialclaimed5/10

   Cal.com supports OAuth 2 authentication with defined scopes (e.g., EVENT_TYPE_WRITE) and API keys manageable in settings, plus 'managed users' independent of a user's own account, which together suggest some scoping/isolation capability. However, there is no explicit documentation of a least-privilege credential system designed specifically for AI agents (e.g., granular per-action scopes, agent-specific key issuance, or expiring/limited-permission tokens). missing for 10: dedicated agent-scoped credential issuance flow, full list of available OAuth scopes, and independent confirmation that scoping is enforced in practice.

   • [claimed-docs] “The Cal.com API has 3 authentication methods: 1. OAuth 2. API key 3. Platform (Deprecated)”
   • [claimed-docs] “You can view and manage your API keys in your settings page under the security tab in Cal.com.”
   • [claimed-docs] “If accessed using an OAuth access token, the `EVENT_TYPE_WRITE` scope is required.”
   • [claimed-docs] “a "managed user" is completely independent of a regular user account on cal.com, meaning you don't need your users to register on cal.com we…”
   • [claimed-docs] “It's important to clarify that a "managed user" is completely independent of a regular user account on cal.com, meaning you don't need your …”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal's docs show OAuth2 and personal access token authentication for its API, but there is no evidence of scope definitions, granular permissions, or least-privilege credential issuance tailored for an agent use case.

   • [claimed-docs] “OAuth 2.0: OAuth2 ... HTTP: Bearer Auth ... Personal access token authentication”
   • [claimed-docs] “OAuth 2.0 authorization code flow ... Personal access token authentication”
   • [claimed-docs] “OAuth 2.0: OAuth2 ... Personal access token authentication ... Bearer format: pt_secret_XXXXXXXXX”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Cal.com
   Cal.com~partialprobed6/10

   Cal.com documents official SDK-like tooling for AI-native builders: a Platform SDK with React atoms and managed users, a full REST API v2 with OAuth/API-key auth, an official CLI recommended for agentic use, and a hosted/local MCP server for natural-language integration. However, evidence lacks a dedicated named client SDK package (e.g., JS/Python) with versioning/changelog, and OpenAPI spec endpoints return 404, undermining programmatic SDK generation claims; community feedback also flags self-hosted API access restrictions and docker/build friction. missing for 10: a discoverable OpenAPI/schema artifact, named official client SDK packages beyond React atoms, and independent hands-on developer corroboration of SDK reliability.

   • [claimed-docs] “a "managed user" is completely independent of a regular user account on cal.com, meaning you don't need your users to register on cal.com we…”
   • [claimed-docs] “Find out how to use Cal "atoms" to integrate scheduling into your product.”
   • [claimed-docs] “Use our react atoms to add scheduling to your app”
   • [claimed-docs] “For agents that can execute commands on a machine, use the official Cal.com CLI instead of calling the API directly.”
   • [claimed-docs] “Connect AI clients to Cal.com scheduling through the Model Context Protocol using the hosted server at mcp.cal.com or a local instance.”
   • [claimed-docs] “The Cal.com API has 3 authentication methods: 1. OAuth 2. API key 3. Platform (Deprecated)”
   • [probe] “PROBE openapi: all candidate paths 404 (https://cal.com/openapi.json, https://cal.com/swagger.json, https://cal.com/api/openapi.json, https:…”
   • [community] “Even if you self-host it, there's no way to self-host the API. You have to pay to use it. So you're just self-hosting the UI. They can chang…”
   • [community] “I self host it, and I self host both the API and the database.”

   proof ↗⚑ flag

   SavvyCal~partialprobed4/10

   SavvyCal offers a documented REST API with OAuth/PAT auth, webhooks, and a JavaScript embed library, giving developers programmatic access, but there is no evidence of official language-specific SDKs (e.g., Python, Node, Ruby) beyond the JS embed script, and probes show no OpenAPI spec or llms.txt available for AI tooling. Missing for 10: dedicated official SDK libraries in multiple languages, published OpenAPI/swagger spec, and AI-discoverable docs (llms.txt) that would support agentic building.

   • [claimed-docs] “The SavvyCal API adheres to REST conventions. Our API communicates in JSON format and uses OAuth access tokens to authenticate requests.”
   • [claimed-docs] “Our JavaScript library allows you to embed your scheduling links on your website (both inline and as a popover).”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.savvycal.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Cal.com✓fullclaimed8/10

   Cal.com's API v2 has documented webhook creation with configurable subscriberUrl and a wide range of triggers (BOOKING_CREATED, BOOKING_RESCHEDULED, BOOKING_CANCELLED, etc.), enabling event-driven subscriptions well-suited to agentic/AI-native integration patterns, and this is reinforced by dedicated AI-agent docs and an official MCP server for programmatic access. Missing for 10: independent/hands-on confirmation of webhook reliability or delivery guarantees, and no evidence of webhook signature verification or retry semantics.

   • [claimed-docs] “BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING_REQUESTED - BOOKING_CANCELLED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING…”
   • [claimed-docs] “The template of the payload that will be sent to the subscriberUrl”
   • [claimed-docs] “If accessed using an OAuth access token, the `EVENT_TYPE_WRITE` scope is required.”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “Connect AI clients to Cal.com scheduling through the Model Context Protocol using the hosted server at mcp.cal.com or a local instance.”

   proof ↗⚑ flag

   SavvyCal✓fullprobed8/10

   SavvyCal has documented webhook support with HTTP POST notifications on account changes, HMAC-SHA256 signature verification, and setup instructions via Settings > Integrations, enabling event-driven subscription for automation/agent use cases. Missing for 10: no independent/hands-on corroboration or public OpenAPI/webhook schema (openapi probe returned 404s), and no explicit list of subscribable event types.

   • [claimed-docs] “Webhooks allow you to listen for changes in a SavvyCal account and get notified via HTTP POST requests.”
   • [claimed-docs] “SavvyCal signs the request body with a SHA-256 HMAC signature. The signature is included in the x-savvycal-signature header.”
   • [claimed-docs] “SavvyCal signs the request body with a SHA-256 HMAC signature.”
   • [claimed-docs] “Navigate to Settings > Integrations and click the + icon in the Webhooks”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   Cal.com—none0/10

   Evidence shows Cal.com exposes an API/MCP server so external AI agents can query availability and create bookings, but this is about agents acting as clients on the user's data, not the product itself surfacing AI-generated insights or suggestions to users. No documentation mentions built-in analytics, pattern-based scheduling suggestions, or AI-generated summaries within the Cal.com product.

   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: **Check availability** - Query available time slots for any user or team * **Create bookings** - Schedu…”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client.”

   proof ↗⚑ flag

   SavvyCal—none0/10

   No evidence of AI-generated insights, analytics, or suggestions surfaced within SavvyCal; the product is a scheduling tool with API/webhook/workflow automation features but nothing about AI-derived insights from user data.

   ⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to SavvyCal
   Cal.com~partialprobed6/10

   Cal.com provides API/webhooks, workflows, MCP server, and an agents.md guide explicitly enabling AI agents to check availability, create/reschedule bookings, and manage event types autonomously via natural language or API calls, which supports background automation. However, these are developer-oriented building blocks requiring the user to wire up their own automation/agent rather than a native built-in 'run autonomously in background' scheduler feature, and no hands-on evidence of an actual autonomous background automation running end-to-end. missing for 10: independent/hands-on validation of an autonomous background automation actually running, native no-code autonomous trigger/scheduling UI (vs. workflows requiring manual setup), and confirmation the MCP/agent integration operates unattended without human-in-the-loop.

   • [claimed-docs] “Connect AI clients to Cal.com scheduling through the Model Context Protocol using the hosted server at mcp.cal.com or a local instance.”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: **Check availability** - Query available time slots for any user or team * **Create bookings** - Schedu…”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client”
   • [claimed-docs] “For agents that can execute commands on a machine, use the official Cal.com CLI instead of calling the API directly.”
   • [claimed-docs] “The booking creation endpoint is public and does not require authentication. This allows agents to book on behalf of external users.”
   • [probe] “official MCP server documented at https://cal.com/docs/mcp-server”

   proof ↗⚑ flag

   SavvyCal✓fullclaimed7/10

   SavvyCal's Workflows feature lets users attach multi-action automations to scheduling links that trigger automatically on meeting lifecycle events (booked, canceled, reminders) without manual intervention, and further extend via Zapier for CRM/task automations — this matches autonomous background automation. Missing for 10: independent/hands-on verification of workflow reliability, evidence of conditional/branching logic or scheduled (non-event-triggered) automations, and any AI-specific automation capability.

   • [claimed-docs] “It’s never been easier to send customized meeting lifecycle messages and automate manual tasks with SavvyCal workflows.”
   • [claimed-docs] “Attach workflows to one or more links to save yourself from repetitive work.”
   • [claimed-docs] “Trigger no-code automations with Zapier ... Sync with your CRM, send yourself reminders, create project management to-do’s…the sky’s the lim…”
   • [claimed-docs] “Keep your automations neatly organized with powerful multi-action workflows.”
   • [claimed-docs] “Create or update CRM records, send yourself reminders, or create to-do’s in your project management software.”
   • [claimed-docs] “Customize the timing and content of your reminders to increase attendance. Compose from scratch or pick one of our handy templates.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   Cal.com—none0/10

   Cal.com's AI-related evidence describes exposing its API/MCP server so external AI agents and clients (e.g., Claude, other MCP clients) can call scheduling functions — it does not describe a built-in AI assistant embedded in the Cal.com product UI that a user can delegate tasks to. This is the inverse of the story (Cal.com as a tool for external agents, not an agent bundled inside Cal.com).

   • [claimed-docs] “Connect AI clients to Cal.com scheduling through the Model Context Protocol using the hosted server at mcp.cal.com or a local instance.”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client”
   • [claimed-docs] “For agents that can execute commands on a machine, use the official Cal.com CLI instead of calling the API directly.”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client.”

   proof ↗⚑ flag

   SavvyCal—none0/10

   The only remotely related item, 'Delegate to an assistant' (savvycal-docs-59), refers to giving a human executive assistant account access on a pricing page, not a built-in AI assistant. No evidence anywhere in the pack of an AI assistant feature users can delegate tasks to within SavvyCal.

   • [claimed-docs] “Delegate to an assistant”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Cal.com
   Cal.com✓fullprobed8/10

   Cal.com documents both a hosted MCP server (mcp.cal.com) and local instance explicitly for controlling bookings, event types, and schedules 'through natural language in any MCP-compatible client,' plus a dedicated agents.md doc for AI agents to check availability, create bookings, and manage event types via API/CLI. This is first-party documented and probe-confirmed (mcp-server doc live at HTTP 200), though there's no independent/community hands-on verification of NL command execution quality. Missing for 10: independent/hands-on evidence of natural-language command execution working reliably in practice.

   • [claimed-docs] “Connect AI clients to Cal.com scheduling through the Model Context Protocol using the hosted server at mcp.cal.com or a local instance.”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client.”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “For agents that can execute commands on a machine, use the official Cal.com CLI instead of calling the API directly.”
   • [probe] “official MCP server documented at https://cal.com/docs/mcp-server”

   proof ↗⚑ flag

   SavvyCal—none0/10

   No evidence of any natural-language command interface, AI assistant, or chat-based control for SavvyCal; the evidence only covers scheduling features, REST API, webhooks, and OAuth. Probes for llms.txt and OpenAPI spec both returned 404, further indicating no AI-native interface layer.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.savvycal.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Cal.com—none0/10

   The evidence pack shows extensive static API reference documentation (markdown pages for bookings, event types, webhooks, etc.) but no evidence of an interactive console or runnable code examples; a probe explicitly found no OpenAPI/Swagger spec at any standard location, suggesting no interactive playground exists. Missing for 10: an interactive API explorer/sandbox, evidence of runnable code snippets, or a Swagger/OpenAPI-based try-it-now interface.

   • [probe] “PROBE docs-md: HTTP 200 at https://cal.com/docs/api-reference/v2/introduction.md > ## Documentation Index > Fetch the complete documentation…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://cal.com/openapi.json, https://cal.com/swagger.json, https://cal.com/api/openapi.json, https:…”
   • [claimed-docs] “The Cal.com API has 3 authentication methods: 1. OAuth 2. API key 3. Platform (Deprecated)”
   • [claimed-docs] “You can view and manage your API keys in your settings page under the security tab in Cal.com.”

   proof ↗⚑ flag

   SavvyCal—none0/10

   Evidence confirms SavvyCal has a REST API with OAuth/bearer/personal-access-token docs, but nothing describes an interactive reference with runnable/try-it examples, and probes for openapi.json/swagger.json/llms.txt all return 404, suggesting no such interactive spec is discoverable.

   • [claimed-docs] “The SavvyCal API adheres to REST conventions. Our API communicates in JSON format and uses OAuth access tokens to authenticate requests.”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.savvycal.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Cal.com—none0/10

   A direct probe of common OpenAPI spec paths (openapi.json, swagger.json, etc.) returned 404 on all candidates, and no documentation page or claimed-docs snippet references a downloadable OpenAPI/Swagger spec file—only human-readable API reference pages and llms.txt indices are evidenced.

   • [probe] “PROBE openapi: all candidate paths 404 (https://cal.com/openapi.json, https://cal.com/swagger.json, https://cal.com/api/openapi.json, https:…”
   • [claimed-docs] “The Cal.com API has 3 authentication methods: 1. OAuth 2. API key 3. Platform (Deprecated)”
   • [probe] “PROBE llms.txt: HTTP 200 at https://cal.com/llms.txt # Cal.com: Scheduling Infrastructure for Individuals, Teams, and Organizations > C…”
   • [probe] “PROBE docs-md: HTTP 200 at https://cal.com/docs/api-reference/v2/introduction.md > ## Documentation Index > Fetch the complete documentation…”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal documents a REST API with OAuth/PAT auth (savvycal-docs-1, -38, -52), and the API reference format (Bearer Auth listings) suggests it may be generated from an OpenAPI schema, but no evidence shows a downloadable OpenAPI/Swagger spec is actually published. Direct probes for openapi.json, swagger.json, and llms.txt all returned 404, contradicting any claim of a machine-readable spec being available.

   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”
   • [claimed-docs] “OAuth 2.0: OAuth2 ... Personal access token authentication ... Bearer format: pt_secret_XXXXXXXXX”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.savvycal.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   Cal.com—none0/10

   The evidence pack contains no mention of a sandbox, staging, or test-mode environment for Cal.com's API, MCP server, or platform atoms — only production API keys, OAuth, and managed users are documented. Self-hosting (Cal.diy) is offered but is explicitly discouraged for production use and not framed as a sandbox for testing against a hosted instance, so it doesn't fulfill this story.

   • [claimed-docs] “The Cal.com API has 3 authentication methods: 1. OAuth 2. API key 3. Platform (Deprecated)”
   • [claimed-docs] “You can view and manage your API keys in your settings page under the security tab in Cal.com.”
   • [claimed-docs] “a "managed user" is completely independent of a regular user account on cal.com, meaning you don't need your users to register on cal.com we…”
   • [github] “Cal.diy is 100% MIT-licensed with no proprietary "Enterprise Edition" features. It's designed for individuals and self-hosters who want full…”
   • [community] “From the docs, 'It is strictly recommended for personal, non-production use.' Wow what a 180 from just a year ago when their blog said on-pr…”

   proof ↗⚑ flag

   SavvyCal—none0/10

   No evidence of a sandbox, test mode, or staging environment for the SavvyCal API; docs only cover REST API, OAuth, webhooks and personal access tokens with no mention of test data isolation.

   • [claimed-docs] “The SavvyCal API adheres to REST conventions. Our API communicates in JSON format and uses OAuth access tokens to authenticate requests.”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to Cal.com
   Cal.com~partialprobed4/10

   Cal.com's API is clearly versioned (all endpoints are under /v2/, and one auth method is explicitly marked 'Platform (Deprecated)'), showing some awareness of versioning and deprecation, but there is no dedicated deprecation policy page, no sunset timeline for v1, and no stated support window for deprecated endpoints/features. missing for 10: explicit documented deprecation policy (timelines, sunset process, migration guides between API versions), evidence of v1→v2 migration guidance, and any independent confirmation that deprecated endpoints are reliably maintained per a stated schedule.

   • [claimed-docs] “The Cal.com API has 3 authentication methods: 1. OAuth 2. API key 3. Platform (Deprecated)”
   • [probe] “PROBE docs-md: HTTP 200 at https://cal.com/docs/api-reference/v2/introduction.md > ## Documentation Index > Fetch the complete documentation…”
   • [claimed-docs] “Authentication to the API is performed via the Authorization header.”

   proof ↗⚑ flag

   SavvyCal—none0/10

   The evidence shows SavvyCal has a REST API with OAuth/PAT authentication, but there is no mention anywhere of API versioning or a documented deprecation policy, and probes for openapi/llms.txt specs failed (404s). Missing for 10: any documentation of API version numbers, changelog, or deprecation/sunset policy.

   • [claimed-docs] “The SavvyCal API adheres to REST conventions. Our API communicates in JSON format and uses OAuth access tokens to authenticate requests.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.savvycal.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

Ai calendar

1. knowledge workerAI finds and continuously optimizes the best meeting time across all attendees' calendars, not just the first open slot

   weight 1 · round to Cal.com
   Cal.com~partialclaimed4/10

   Cal.com's API supports querying mutual availability across multiple attendees via the 'by usernames only' dynamic event type, and its agents.md docs let AI agents check availability and create bookings, which gives a building block for finding open slots across calendars. However there is no evidence of any optimization logic that ranks or continuously re-evaluates the 'best' time (e.g., factoring preferences, meeting quality, or re-optimizing after changes) beyond returning available slots for manual/first-fit selection. Missing for 10: evidence of an AI/optimization algorithm scoring or ranking candidate times, evidence of continuous re-optimization as calendars change, and any documented 'best time' selection logic beyond raw slot listing.

   • [claimed-docs] “There are 4 ways to get available slots for event type of an individual user: 1. By event type id. ... 4. By usernames only (used for dynami…”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: **Check availability** - Query available time slots for any user or team * **Create bookings** - Schedu…”
   • [claimed-docs] “Check availability - Query available time slots for any user or team”
   • [claimed-docs] “There are 4 ways to get available slots for event type of an individual user”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal offers collective/round-robin availability views and 'ranked availability windows' but these are rule-based scheduling features, not an AI system that finds and continuously re-optimizes the best time as calendars change; no evidence of any AI/ML-driven optimization engine is present in the evidence pack.

   • [claimed-docs] “Show collective availability to book any available team member.”
   • [claimed-docs] “Present ranked availability windows to encourage recipients to pick the optimal time (while still remaining flexible).”
   • [claimed-docs] “Show combined availability for your whole team and automatically route each booked meeting to the right person.”

   proof ↗⚑ flag

2. knowledge workerAI schedules my tasks into real calendar blocks around meetings and deadlines, and re-plans automatically when things change

   weight 2 · round drawn
   Cal.com—none0/10

   Cal.com's API/MCP lets AI agents check availability, create bookings, and reschedule meetings (cal-com-docs-12, cal-com-docs-24, cal-com-docs-49), but there is no evidence of an AI system that autonomously blocks time for tasks/deadlines around a knowledge worker's existing meetings or automatically re-plans a schedule when things change — it's a booking/meeting API, not a task-time-blocking planner.

   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “Reschedule a booking or seated booking. Reschedulable booking statuses: - `accepted` — the confirmed booking is moved to the new start time.…”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client.”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: **Check availability** - Query available time slots for any user or team * **Create bookings** - Schedu…”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal is a scheduling-link tool with API/webhooks/workflows, but there is no evidence of AI-driven autonomous task scheduling into calendar blocks or automatic re-planning around deadlines/meetings; its 'workflows' are manual/trigger-based automations, not AI task planning.

   • [claimed-docs] “Budget your time using calendar events, and wire up SavvyCal to honor those preferences.”
   • [claimed-docs] “It’s never been easier to send customized meeting lifecycle messages and automate manual tasks with SavvyCal workflows.”
   • [claimed-docs] “Keep your automations neatly organized with powerful multi-action workflows.”

   proof ↗⚑ flag

3. knowledge workerThe product auto-defends recurring focus time and habits, flexibly moving them when conflicts appear instead of dropping them

   weight 2 · round drawn
   Cal.com—none0/10

   Cal.com's evidence covers booking, rescheduling, scheduling APIs, webhooks, and AI-agent integration, but nothing describes an autonomous system that 'defends' recurring focus time/habit blocks by detecting conflicts and proactively rescheduling them rather than dropping them. Reschedule endpoints exist but are manually/API-triggered, not an autonomous focus-time-protection feature.

   • [claimed-docs] “Reschedule a booking or seated booking.”
   • [claimed-docs] “Reschedule a booking or seated booking. Reschedulable booking statuses: - `accepted` — the confirmed booking is moved to the new start time.…”
   • [claimed-docs] “The point of creating schedules is for event types to be available at specific times.”
   • [claimed-docs] “POST /v2/bookings is used to create regular bookings, recurring bookings and instant bookings.”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal's evidence covers scheduling links, availability, round robin, workflows, and payments, but there is no mention of auto-defending recurring focus time/habits or dynamically rescheduling blocked time when conflicts arise. The 'budget your time using calendar events' feature (docs-12) is the closest but only describes honoring preferences during booking, not proactive conflict-driven rescheduling of habits.

   • [claimed-docs] “Budget your time using calendar events, and wire up SavvyCal to honor those preferences.”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Cal.com—none0/10

   The evidence describes single-resource CRUD operations (create one booking, reschedule one booking, create one event type, one webhook) via the API, but no bulk/batch endpoints (e.g., bulk booking creation, bulk cancellation, mass event-type updates) are documented anywhere in the pack.

   ⚑ flag

   SavvyCal—none0/10

   SavvyCal exposes a REST API and webhooks, which could in principle support bulk operations, but no evidence describes any batch/bulk endpoints, batch scheduling actions, or bulk update/import/export capability across links, meetings, or contacts.

   • [claimed-docs] “The SavvyCal API adheres to REST conventions. Our API communicates in JSON format and uses OAuth access tokens to authenticate requests.”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to SavvyCal
   Cal.com~partialclaimed6/10

   Cal.com supports webhooks with configurable triggers (BOOKING_CREATED, BOOKING_PAID, BOOKING_CANCELLED, etc.) that fire actions on events, plus Zapier integration for further automation chains, which together enable rule-like 'if event X, do action Y' automation. However, this is trigger-based webhook automation rather than a native conditional rules engine (no evidence of if/then logic, filtering conditions, or multi-step workflow builder beyond routing forms). Missing for 10: evidence of a native conditional/rules engine with branching logic, non-webhook native workflow automation, and independent hands-on confirmation that webhook-triggered automations work reliably in practice.

   • [claimed-docs] “BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING_REQUESTED - BOOKING_CANCELLED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING…”
   • [claimed-docs] “The template of the payload that will be sent to the subscriberUrl”
   • [claimed-docs] “Workflow automation for everyone. Use the Cal.com Zapier app to automate your workflows when a booking is created, rescheduled, cancelled or…”
   • [claimed-docs] “Retrieve the step-by-step routing trace for a booking identified by its UID. Shows how the booking was routed through routing forms, CRM loo…”
   • [claimed-docs] “Shows how the booking was routed through routing forms, CRM lookups, and host selection logic.”

   proof ↗⚑ flag

   SavvyCal~partialclaimed7/10

   SavvyCal's Workflows feature lets users attach multi-action automations to scheduling links that trigger on meeting lifecycle events (booked, reminder, follow-up), and webhooks plus Zapier extend this to external CRM/task actions, which is genuine event-driven automation. However the evidence shows this is scoped to meeting-lifecycle triggers rather than general conditional rule logic (if/then branching) across arbitrary events. Missing for 10: documented conditional/branching rule syntax, evidence of custom trigger conditions beyond meeting stages, and independent/hands-on confirmation of workflow reliability.

   • [claimed-docs] “It’s never been easier to send customized meeting lifecycle messages and automate manual tasks with SavvyCal workflows.”
   • [claimed-docs] “Attach workflows to one or more links to save yourself from repetitive work.”
   • [claimed-docs] “Keep your automations neatly organized with powerful multi-action workflows.”
   • [claimed-docs] “Create or update CRM records, send yourself reminders, or create to-do’s in your project management software.”
   • [claimed-docs] “Trigger no-code automations with Zapier ... Sync with your CRM, send yourself reminders, create project management to-do’s…the sky’s the lim…”
   • [claimed-docs] “Webhooks allow you to listen for changes in a SavvyCal account and get notified via HTTP POST requests.”
   • [claimed-docs] “Navigate to Settings > Integrations and click the + icon in the Webhooks”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Cal.com
   Cal.com~partialclaimed6/10

   Cal.com's API explicitly supports creating recurring bookings (`POST /v2/bookings` creates 'regular bookings, recurring bookings and instant bookings') and the platform has a native 'workflows' feature plus webhooks for automation triggers, and this API/webhook layer is documented as usable by AI agents and via the official MCP server. However, no evidence directly shows an AI agent invoking recurring-schedule creation through MCP/agent docs, nor detail on how recurring jobs are configured/managed beyond the one-line API mention. Missing for 10: hands-on/independent proof of an AI agent actually creating a recurring booking via MCP or the agents API, and deeper documentation of the 'workflows' automation feature.

   • [claimed-docs] “POST /v2/bookings is used to create regular bookings, recurring bookings and instant bookings.”
   • [claimed-docs] “It powers one-on-one, group, round-robin, and collective scheduling, with routing forms, workflows, payments, native video, and an app store…”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client.”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING_REQUESTED - BOOKING_CANCELLED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal's 'workflows' feature (docs-15/16/25/26) triggers actions based on meeting lifecycle events (booking, reminders, CRM updates), not on a recurring/cron-like schedule independent of a meeting trigger; there is no evidence of scheduling arbitrary recurring jobs or workflows for AI-native automation.

   • [claimed-docs] “It’s never been easier to send customized meeting lifecycle messages and automate manual tasks with SavvyCal workflows.”
   • [claimed-docs] “Attach workflows to one or more links to save yourself from repetitive work.”
   • [claimed-docs] “Keep your automations neatly organized with powerful multi-action workflows.”
   • [claimed-docs] “Create or update CRM records, send yourself reminders, or create to-do’s in your project management software.”
   • [claimed-docs] “Trigger no-code automations with Zapier ... Sync with your CRM, send yourself reminders, create project management to-do’s…the sky’s the lim…”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Cal.com—none0/10

   Cal.com is a scheduling platform; its evidence pack covers bookings, event types, webhooks, MCP/AI-agent integrations, and self-hosting, but nothing describes versioning, review workflows, or rollback of automations/workflows themselves. No changelog, audit trail, or undo mechanism for automation configurations is documented.

   ⚑ flag

   SavvyCal—none0/10

   SavvyCal offers workflows/automations (docs-15, docs-16, docs-25) but there is no evidence of any version history, change review, diffing, or rollback capability for these automations or workflows.

   ⚑ flag

Booking

1. founderShare a booking link where invitees pick a time from my live availability — no back-and-forth email

   weight 3 · round drawn
   Cal.com✓fullcommunity9/10

   Cal.com's own docs directly state the exact value proposition: 'Share a booking link, connect your calendars, and let people pick a time without the back-and-forth,' backed by API/product features like available-slots lookup, event types, and scheduling configuration that make this work, and community feedback confirms real-world usage replacing manual scheduling (e.g. switching from Calendly due to UX). Missing for 10: independent hands-on verification of the live-availability booking flow itself (most corroboration is docs-based) and no dispute exists to weigh against.

   • [claimed-docs] “Share a booking link, connect your calendars, and let people pick a time without the back-and-forth.”
   • [claimed-docs] “It powers one-on-one, group, round-robin, and collective scheduling, with routing forms, workflows, payments, native video, and an app store…”
   • [claimed-docs] “There are 4 ways to get available slots for event type of an individual user: 1. By event type id.”
   • [claimed-docs] “Create a schedule for the authenticated user. The point of creating schedules is for event types to be available at specific times.”
   • [community] “Happily using it for several months now after getting frustrated with calendly's UX.”

   proof ↗⚑ flag

   SavvyCal✓fullclaimed9/10

   SavvyCal's core product is booking links that show live availability, embeddable via widget/hyperlink/JS, with calendar overlay so invitees pick a mutual time without email back-and-forth. This is well documented across multiple first-party pages. Missing for 10: independent/third-party hands-on corroboration beyond vendor docs.

   • [claimed-docs] “Adjust the colors, banner image, and avatar that appear on your links to match your unique style.”
   • [claimed-docs] “Host your scheduling links on your own custom domain, for a professional white-labeled booking experience.”
   • [claimed-docs] “Recipients can even overlay their calendar on top of your link to spot ideal times at a glance!”
   • [claimed-docs] “The recipient can view their calendar events on top of your scheduling link, to save them the hassle of clicking back and forth.”
   • [claimed-docs] “Let visitors schedule time without ever leaving your website. Trigger your embedded link via hyperlink, the floating button, or a JavaScript…”
   • [claimed-docs] “Generate a snippet of text to propose times in just seconds. Recipients can pick a time to meet in just two clicks.”

   proof ↗⚑ flag

2. founderOffer multiple event types with their own durations, locations, custom questions, and confirmation rules

   weight 2 · round to Cal.com
   Cal.com✓fullclaimed9/10

   Docs confirm event types support multiple durations (docs-4), custom locations including video/conferencing apps (docs-7, docs-21), custom booking-form questions/fields (docs-40, docs-59), and confirmation/scheduling logic including round-robin and requested/accepted booking states (docs-25, docs-58). This covers durations, locations, custom questions, and confirmation rules comprehensively via first-party API docs. Missing for 10: independent/hands-on verification of the full event-type creation UI flow beyond docs.

   • [claimed-docs] “If you want that user can choose between different lengths of the event you can specify them here.”
   • [claimed-docs] “Every Cal.com booking gets a location. By default that is Cal Video, and you can point it at Zoom, Microsoft Teams or Google Meet instead on…”
   • [claimed-docs] “Connect Zoom, Microsoft Teams or Google Meet to a user or a team”
   • [claimed-docs] “Custom fields that can be added to the booking form when the event is booked by someone. By default booking form has name and email field.”
   • [claimed-docs] “Provide `bookingFields` to customize the default fields or add custom booking fields.”
   • [claimed-docs] “roundRobin: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings (weights togg…”
   • [claimed-docs] “Reschedulable booking statuses: - `accepted` — the confirmed booking is moved to the new start time. - `pending` — a booking awaitin…”
   • [claimed-docs] “Create an event type”

   proof ↗⚑ flag

   SavvyCal~partialclaimed4/10

   Evidence confirms SavvyCal supports multiple customizable scheduling links (branding, payment integration, booking limits, workflows attached to links), implying separate 'event types' per link, but nothing in the pack explicitly documents per-link duration settings, location options, custom intake questions, or confirmation/approval rules. missing for 10: explicit docs on setting duration per link, location fields, custom questions builder, and confirmation-required vs auto-confirm booking rules.

   • [claimed-docs] “Connect your link to a corresponding product in your Stripe account and require payment before reserving the meeting time.”
   • [claimed-docs] “Limit how many meetings are allowed on a per-day, week, and month basis.”
   • [claimed-docs] “Attach workflows to one or more links to save yourself from repetitive work.”
   • [claimed-docs] “Adjust the colors, banner image, and avatar that appear on your links to match your unique style.”
   • [claimed-docs] “Host your scheduling links on your own custom domain, for a professional white-labeled booking experience.”
   • [claimed-docs] “Prevent meeting overload and cap quantity per day, week, and month.”

   proof ↗⚑ flag

Booking controls

1. knowledge workerProtect my calendar with buffers before and after meetings, minimum notice, daily booking caps, and date-range windows

   weight 2 · round to SavvyCal
   Cal.com—none0/10

   The evidence pack covers scheduling infrastructure (schedules, event types, webhooks, routing) but contains no documentation or mention of buffer times before/after meetings, minimum booking notice, daily booking caps, or date-range availability windows — the specific booking-protection controls this story asks about.

   ⚑ flag

   SavvyCal~partialclaimed5/10

   SavvyCal explicitly documents daily/weekly/monthly booking caps (docs-11, docs-36) and 'budget your time' calendar-based preferences that could relate to buffers/notice (docs-12), but there is no explicit mention of configurable pre/post-meeting buffers, minimum notice period, or date-range availability windows in the evidence pack. missing for 10: explicit buffer-before/after-meeting settings, minimum notice period configuration, and date-range window limits.

   • [claimed-docs] “Limit how many meetings are allowed on a per-day, week, and month basis.”
   • [claimed-docs] “Prevent meeting overload and cap quantity per day, week, and month.”
   • [claimed-docs] “Budget your time using calendar events, and wire up SavvyCal to honor those preferences.”

   proof ↗⚑ flag

2. founderCollect payment (e.g. via Stripe) at the moment of booking for paid sessions

   weight 1 · round to SavvyCal
   Cal.com~partialclaimed5/10

   Cal.com's docs list "payments" among core platform capabilities (cal-com-docs-28/48) and webhook events explicitly include BOOKING_PAYMENT_INITIATED and BOOKING_PAID, confirming a payment-at-booking flow exists (cal-com-docs-5/26/42). However, the evidence pack lacks any Stripe-specific setup docs, API fields for configuring a paid event type, or a hands-on confirmation that a booking actually triggers a Stripe charge. Missing for 10: dedicated Stripe/payment-app integration docs, API examples showing price/currency fields on event-type creation, and independent/hands-on verification of a successful paid booking flow.

   • [claimed-docs] “It powers one-on-one, group, round-robin, and collective scheduling, with routing forms, workflows, payments, native video, and an app store…”
   • [claimed-docs] “Cal.com's differentiators are the self-hostable MIT edition (Cal.diy), API-first architecture, regulated-industry compliance, organization-s…”
   • [claimed-docs] “BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING_REQUESTED - BOOKING_CANCELLED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING…”

   proof ↗⚑ flag

   SavvyCal✓fullclaimed8/10

   SavvyCal's docs explicitly describe connecting a Stripe product to a scheduling link and requiring payment before reserving the meeting time, plus Stripe Tax support for sales tax/VAT/GST and native management of offerings/pricing within SavvyCal. This directly matches the founder story of collecting payment at booking. Missing for 10: independent/hands-on verification of the payment flow (all evidence is vendor docs) and no detail on payment failure/refund handling.

   • [claimed-docs] “Connect your link to a corresponding product in your Stripe account and require payment before reserving the meeting time.”
   • [claimed-docs] “Calculate and collect sales tax, VAT, and GST with the click of a button (powered by Stripe Tax).”
   • [claimed-docs] “You don’t even have to leave SavvyCal to create new offerings or adjust your prices. Do it all natively within SavvyCal.”
   • [claimed-docs] “Connect your Stripe account to collect payments on your scheduling links. Collect sales tax if needed & accept any payment method available …”

   proof ↗⚑ flag

3. knowledge workerInvitees always see slots in their own time zone — detection, display, and DST handling are automatic

   weight 3 · round drawn
   Cal.com—none0/10

   The evidence pack contains no documentation or mention of timezone auto-detection, timezone display to invitees, or DST handling — only generic booking-link and API/event-type documentation. This is a fair and applicable axis for a scheduling product, but nothing in the pack substantiates it. Missing for 10: any docs on invitee timezone detection, timezone conversion display, or DST-safe scheduling logic.

   ⚑ flag

   SavvyCal—none0/10

   No evidence pack item mentions time zone detection, display, or DST handling for invitees; the docs focus on API, webhooks, embedding, team scheduling, and payments but never address time zone automation.

   ⚑ flag

Calendars

1. knowledge workerBusy blocks sync between my work and personal calendars automatically so all my schedules stay in step

   weight 2 · round to SavvyCal
   Cal.com~partialclaimed3/10

   Cal.com's docs mention connecting your calendars so people can book around your availability (cal-com-docs-16, cal-com-docs-28), implying calendar sync is core to the platform, but the evidence pack never details two-way busy-block sync across multiple work/personal calendars, conflict-checking logic, or write-back behavior. missing for 10: explicit documentation of multi-calendar busy-block overlay/sync, two-way write-back, and any hands-on confirmation that it keeps personal and work calendars in step.

   • [claimed-docs] “Share a booking link, connect your calendars, and let people pick a time without the back-and-forth.”
   • [claimed-docs] “It powers one-on-one, group, round-robin, and collective scheduling, with routing forms, workflows, payments, native video, and an app store…”

   proof ↗⚑ flag

   SavvyCal~partialclaimed5/10

   SavvyCal's docs reference including external/multiple calendars in availability checks and budgeting time via calendar events, implying busy blocks from connected calendars feed into scheduling, but no evidence explicitly describes connecting a personal AND work calendar and syncing busy blocks automatically between them for an individual user's own scheduling link. missing for 10: explicit documentation of multi-calendar (work+personal) connection and automatic busy-block sync for a single user, plus independent/hands-on confirmation.

   • [claimed-docs] “Include external calendars when showing team availability.”
   • [claimed-docs] “Budget your time using calendar events, and wire up SavvyCal to honor those preferences.”
   • [claimed-docs] “Allow recipients to overlay their calendar on top of yours to easily find mutual availability.”
   • [claimed-docs] “The recipient can view their calendar events on top of your scheduling link, to save them the hassle of clicking back and forth.”

   proof ↗⚑ flag

2. knowledge workerConnect several calendars (Google, Outlook, Apple) and every one is checked for conflicts so I never get double-booked

   weight 3 · round to Cal.com
   Cal.com~partialclaimed3/10

   The evidence pack only contains a single generic line ('connect your calendars... pick a time without the back-and-forth') suggesting calendar sync exists, but nothing details Google/Outlook/Apple-specific connections or explicit cross-calendar conflict-checking logic. Missing for 10: explicit documentation of Google/Outlook/Apple calendar integrations, description of two-way sync/conflict-avoidance mechanics, and independent corroboration that double-booking is prevented across multiple connected calendars.

   • [claimed-docs] “Share a booking link, connect your calendars, and let people pick a time without the back-and-forth.”

   proof ↗⚑ flag

   SavvyCal—none0/10

   The evidence pack covers API/webhooks, round-robin scheduling, payments, and workflows, but contains no mention of connecting multiple external calendars (Google/Outlook/Apple) or cross-calendar conflict checking for double-booking prevention — the closest items reference 'external calendars' only in the context of team availability aggregation, not personal multi-calendar conflict-checking.

   • [claimed-docs] “Include external calendars when showing team availability.”

   proof ↗⚑ flag

3. knowledge workerDefine availability schedules with working hours, date overrides, and out-of-office periods

   weight 2 · round to Cal.com
   Cal.com✓fullclaimed8/10

   Cal.com docs explicitly describe creating schedules with working hours ('Create a schedule for the authenticated user... available at specific times'), and the scheduling configuration endpoint references advanced availability settings; the platform is widely known for date overrides and OOO via its UI, and the API-level schedule creation endpoint supports these core scheduling primitives. Missing for 10: explicit documentation snippet showing date-override and out-of-office API/UI fields, and independent hands-on confirmation of these specific sub-features beyond schedule creation.

   • [claimed-docs] “Create a schedule for the authenticated user. The point of creating schedules is for event types to be available at specific times.”
   • [claimed-docs] “The point of creating schedules is for event types to be available at specific times.”
   • [claimed-docs] “roundRobin: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings (weights togg…”
   • [claimed-docs] “**roundRobin**: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings (weights …”
   • [claimed-docs] “It powers one-on-one, group, round-robin, and collective scheduling, with routing forms, workflows, payments, native video, and an app store…”

   proof ↗⚑ flag

   SavvyCal~partialclaimed3/10

   Evidence only tangentially references availability settings — 'preset work hours' for round-robin links and 'budget your time using calendar events' to honor scheduling preferences — but there is no explicit documentation of a full availability-schedule builder with working hours, date overrides, or dedicated out-of-office periods. missing for 10: explicit docs on defining weekly working-hour schedules, date-specific overrides, and out-of-office blocking.

   • [claimed-docs] “Budget your time using calendar events, and wire up SavvyCal to honor those preferences.”
   • [claimed-docs] “Team members can set custom availability for each round robin scheduling link or default to their preset work hours.”
   • [claimed-docs] “Limit how many meetings are allowed on a per-day, week, and month basis.”
   • [claimed-docs] “Prevent meeting overload and cap quantity per day, week, and month.”

   proof ↗⚑ flag

Platform

1. developerWebhooks notify my systems in real time when bookings are created, rescheduled, or canceled

   weight 2 · round drawn
   Cal.com✓fullclaimed8/10

   Cal.com's API v2 docs explicitly document a webhook resource with triggers including BOOKING_CREATED, BOOKING_RESCHEDULED, BOOKING_CANCELLED, BOOKING_PAID, etc., configurable subscriberUrl and payload template, directly matching the story of real-time booking event notifications. Evidence is first-party docs only, without independent/hands-on confirmation of webhook delivery reliability. missing for 10: independent/hands-on verification of webhook delivery in production, details on retry/failure handling.

   • [claimed-docs] “BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING_REQUESTED - BOOKING_CANCELLED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING…”
   • [claimed-docs] “The template of the payload that will be sent to the subscriberUrl”
   • [claimed-docs] “If accessed using an OAuth access token, the `EVENT_TYPE_WRITE` scope is required.”

   proof ↗⚑ flag

   SavvyCal✓fullclaimed8/10

   SavvyCal docs explicitly describe webhooks for listening to account changes via HTTP POST, with HMAC-SHA256 signature verification and setup instructions via Settings > Integrations. Missing for 10: explicit enumeration of specific event types (booking created/rescheduled/canceled) and independent/hands-on confirmation of real-time delivery reliability.

   • [claimed-docs] “Webhooks allow you to listen for changes in a SavvyCal account and get notified via HTTP POST requests.”
   • [claimed-docs] “SavvyCal signs the request body with a SHA-256 HMAC signature. The signature is included in the x-savvycal-signature header.”
   • [claimed-docs] “SavvyCal signs the request body with a SHA-256 HMAC signature.”
   • [claimed-docs] “Navigate to Settings > Integrations and click the + icon in the Webhooks”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”

   proof ↗⚑ flag

2. developerA documented REST API lets me manage event types, availability, and bookings programmatically — enough to build scheduling into my own product

   weight 3 · round to Cal.com
   Cal.com✓fullprobed9/10

   Cal.com provides extensive documented REST API v2 endpoints for creating/rescheduling bookings, creating event types, availability schedules, webhooks, and scheduling configuration, plus authentication via OAuth/API keys, directly enabling developers to build scheduling into their own product. missing for 10: no independently discoverable OpenAPI/swagger spec (probe found 404s) and no hands-on third-party developer corroboration of API reliability beyond vendor docs.

   • [claimed-docs] “Provide `eventTypeSlug` and `username` and optionally `organizationSlug` if the user with the username is within an organization.”
   • [claimed-docs] “If you want that user can choose between different lengths of the event you can specify them here.”
   • [claimed-docs] “Create a schedule for the authenticated user. The point of creating schedules is for event types to be available at specific times.”
   • [claimed-docs] “There are 4 ways to get available slots for event type of an individual user”
   • [claimed-docs] “Reschedule a booking or seated booking. Reschedulable booking statuses: - `accepted` — the confirmed booking is moved to the new start time.…”
   • [claimed-docs] “The Cal.com API has 3 authentication methods: 1. OAuth 2. API key 3. Platform (Deprecated)”
   • [claimed-docs] “Authentication to the API is performed via the Authorization header.”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://cal.com/openapi.json, https://cal.com/swagger.json, https://cal.com/api/openapi.json, https:…”

   proof ↗⚑ flag

   SavvyCal~partialprobed6/10

   SavvyCal documents a REST API with OAuth2/personal-access-token auth and a 'SavvyCal Meetings API' plus webhooks and a JS embed library, indicating programmatic access to scheduling functionality. However, the evidence never specifies concrete endpoints for event types, availability, or bookings, and probes show no discoverable OpenAPI/swagger spec or llms.txt, leaving the exact API surface unconfirmed. Missing for 10: explicit endpoint/resource documentation for event types, availability, and bookings, and a machine-readable API spec (404s on openapi.json/swagger.json).

   • [claimed-docs] “The SavvyCal API adheres to REST conventions. Our API communicates in JSON format and uses OAuth access tokens to authenticate requests.”
   • [claimed-docs] “OAuth 2.0: OAuth2 ... HTTP: Bearer Auth ... Personal access token authentication”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”
   • [claimed-docs] “OAuth 2.0: OAuth2 ... Personal access token authentication ... Bearer format: pt_secret_XXXXXXXXX”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

3. developerSelf-host the full scheduling engine from source or a container image under an open-source license

   weight 2 · round to Cal.com
   Cal.com!disputedcontradicted4/10

   Cal.com ships an MIT-licensed, no-license-key-required fork (Cal.diy) explicitly marketed for self-hosters (cal-com-gh-1/2/3/4/5), but hands-on community reports concretely contradict full self-hosting viability: the vendor reportedly stopped providing public Docker images (requiring users to build from source themselves) and now recommends the OSS edition 'strictly for personal, non-production use' after previously advertising full infrastructure ownership (cal-com-comm-14, cal-com-comm-15, cal-com-comm-19), and earlier reports describe broken/undocumented docker-compose setups and API access requiring a hosted paid service (cal-com-comm-3, cal-com-comm-4, cal-com-comm-11), though at least one user reports successfully self-hosting both API and DB (cal-com-comm-12). missing for 10: a consistent, current first-party guarantee of a working container image and full production-grade self-host path that isn't contradicted by these recent community reports.

   • [github] “Cal.diy is 100% MIT-licensed with no proprietary "Enterprise Edition" features. It's designed for individuals and self-hosters who want full…”
   • [github] “Cal.diy is the community-driven, fully open-source scheduling platform — a fork of Cal.com with all enterprise/commercial code removed.”
   • [github] “Cal.diy** is the community-driven, fully open-source scheduling platform — a fork of [Cal.com](https://cal.com) with all enterprise/commerci…”
   • [github] “Cal.diy is **100% MIT-licensed** with no proprietary "Enterprise Edition" features. It's designed for individuals and self-hosters who want …”
   • [github] “No license key required — Everything works out of the box, no Cal.com account or license needed”
   • [community] “Even if you self-host it, there's no way to self-host the API. You have to pay to use it. So you're just self-hosting the UI. They can chang…”
   • [community] “the problem with cal.com 'open source' self-hosting is that they have made it quite difficult to run yourself... this actually doesn't provi…”
   • [community] “Also the docker compose in the repo is a mess and doesn't work... Clearly it seems to be a way to limit usage of the selfhosted version.”
   • [community] “I self host it, and I self host both the API and the database.”
   • [community] “It’s curious what they said in the email they sent me about the OSS version... We will no longer provide public Docker images, so your team …”
   • [community] “From the docs, 'It is strictly recommended for personal, non-production use.' Wow what a 180 from just a year ago when their blog said on-pr…”
   • [community] “Their docs say cal.fyi won't have team features but my self hosted one does. They are a bit hacky... I think they also said they will stop p…”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal is a hosted SaaS scheduling product; evidence shows only a REST API, webhooks, and JS embed for integration, with a page listing 'open-source contributions' but no self-hostable engine, source release, or container image. No evidence of any self-hosting capability under an open-source license.

   • [claimed-docs] “Here are some of our contributions to the community”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”

   proof ↗⚑ flag

Embeds

1. sales leadBookings flow into my CRM and automation stack (Salesforce, HubSpot, Zapier) without manual copying

   weight 2 · round drawn
   Cal.com~partialclaimed6/10

   Cal.com exposes webhooks (BOOKING_CREATED, BOOKING_PAID, BOOKING_RESCHEDULED, etc.) and a general-purpose API/OAuth layer that could feed a CRM or Zapier via automation, and routing-form docs reference 'CRM lookups' and 'CRM fallback' in host-selection logic, plus an 'app store of integrations' is claimed. However, there is no direct evidence of a native Salesforce, HubSpot, or Zapier app/connector, nor of an out-of-the-box no-code integration flow — only the building blocks (webhooks + API) that a sales lead would need someone to wire up. Missing for 10: explicit documentation or listing of a Salesforce/HubSpot/Zapier native app, an official Zapier integration page, and any hands-on/independent confirmation that bookings actually sync into these CRMs.

   • [claimed-docs] “BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING_REQUESTED - BOOKING_CANCELLED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING…”
   • [claimed-docs] “Retrieve the step-by-step routing trace for a booking identified by its UID. Shows how the booking was routed through routing forms, CRM loo…”
   • [claimed-docs] “It powers one-on-one, group, round-robin, and collective scheduling, with routing forms, workflows, payments, native video, and an app store…”
   • [claimed-docs] “Authentication to the API is performed via the Authorization header.”

   proof ↗⚑ flag

   SavvyCal~partialclaimed6/10

   SavvyCal explicitly supports Zapier for CRM syncing and workflow automations (create/update CRM records), plus webhooks and a REST API for custom integrations, which together enable bookings to flow into CRM/automation stacks without manual copying. However, there is no evidence of native, first-party Salesforce or HubSpot integrations — only generic Zapier and webhook/API-based paths, which require setup/configuration rather than a turnkey connection. Missing for 10: dedicated Salesforce/HubSpot native integrations, documented pre-built Zaps or CRM field-mapping templates, and independent case studies confirming reliable no-manual-copy CRM sync in practice.

   • [claimed-docs] “Trigger no-code automations with Zapier ... Sync with your CRM, send yourself reminders, create project management to-do’s…the sky’s the lim…”
   • [claimed-docs] “Create or update CRM records, send yourself reminders, or create to-do’s in your project management software.”
   • [claimed-docs] “Trigger no-code automations with Zapier Sync with your CRM, send yourself reminders, create project management to-do’s…the sky’s the limit.”
   • [claimed-docs] “Webhooks allow you to listen for changes in a SavvyCal account and get notified via HTTP POST requests.”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”

   proof ↗⚑ flag

2. developerEmbed the booking experience in my own site — inline, popup, or floating widget — with a documented snippet

   weight 2 · round to SavvyCal
   Cal.com—none0/10

   The evidence pack lacks any explicit documentation of an embed.js-style snippet supporting inline, popup, and floating widget modes. It only mentions React 'atoms' for building custom scheduling UI in an app (cal-com-docs-10, cal-com-docs-36, cal-com-docs-54), which is a different integration method (framework components, not a drop-in snippet) and requires managed users rather than a simple embed code. Missing for 10: documented embed.js snippet, inline/popup/floating-button embed modes, and any non-React (plain HTML/JS) usage example.

   • [claimed-docs] “Find out how to use Cal "atoms" to integrate scheduling into your product.”
   • [claimed-docs] “Use our react atoms to add scheduling to your app”
   • [claimed-docs] “This allows you to connect your users to Cal and handle their scheduling with atoms.”

   proof ↗⚑ flag

   SavvyCal✓fullclaimed8/10

   SavvyCal documents a JavaScript embed library supporting inline, popover, and floating widget embeds, plus hyperlink/JS-call triggers, matching the story closely (savvycal-docs-2, savvycal-docs-18, savvycal-docs-49, savvycal-docs-52). Missing for 10: a directly-quoted code snippet in the evidence pack and independent/hands-on confirmation of the embed working on a third-party site.

   • [claimed-docs] “Our JavaScript library allows you to embed your scheduling links on your website (both inline and as a popover).”
   • [claimed-docs] “Display scheduling links inline, via a floating widget, or triggered based clicking a hyperlink.”
   • [claimed-docs] “Let visitors schedule time without ever leaving your website. Trigger your embedded link via hyperlink, the floating button, or a JavaScript…”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”

   proof ↗⚑ flag

Workflows

1. sales leadAutomated reminder and follow-up sequences (email/SMS) fire around every booking to cut no-shows

   weight 2 · round to SavvyCal
   Cal.com~partialclaimed3/10

   Evidence only indirectly supports this: llms.txt lists 'workflows' as a product capability and mentions 'no-show calculations' in round-robin config, and webhooks (BOOKING_CREATED/RESCHEDULED/CANCELLED) plus a Zapier app that 'automates workflows when a booking is created, rescheduled, cancelled' could be used to build reminder/follow-up sequences. However, no evidence explicitly documents built-in automated email/SMS reminder sequences targeting no-show reduction. Missing for 10: dedicated docs on the Workflows feature's reminder/SMS templates, timing/triggers configuration, and any data or claims about no-show reduction impact.

   • [claimed-docs] “It powers one-on-one, group, round-robin, and collective scheduling, with routing forms, workflows, payments, native video, and an app store…”
   • [claimed-docs] “**roundRobin**: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings (weights …”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED”
   • [claimed-docs] “Workflow automation for everyone. Use the Cal.com Zapier app to automate your workflows when a booking is created, rescheduled, cancelled or…”

   proof ↗⚑ flag

   SavvyCal~partialclaimed6/10

   SavvyCal's Workflows feature explicitly supports sending customized 'meeting lifecycle messages' with adjustable timing and content designed 'to minimize no-shows,' plus Zapier integration for further automation (e.g., SMS via third-party apps). However, native SMS reminders are not documented—only email-based workflow messages and templates are described, with SMS presumably requiring Zapier/CRM integration rather than being built-in. missing for 10: native SMS reminder capability, evidence of automatic sequencing/multi-touch cadence beyond single reminders, independent confirmation of no-show reduction impact.

   • [claimed-docs] “It’s never been easier to send customized meeting lifecycle messages and automate manual tasks with SavvyCal workflows.”
   • [claimed-docs] “Attach workflows to one or more links to save yourself from repetitive work.”
   • [claimed-docs] “Keep your automations neatly organized with powerful multi-action workflows.”
   • [claimed-docs] “Customize your timing and content to minimize no-shows. Compose from scratch or pick one of our handy templates.”
   • [claimed-docs] “Customize the timing and content of your reminders to increase attendance. Compose from scratch or pick one of our handy templates.”
   • [claimed-docs] “Trigger no-code automations with Zapier ... Sync with your CRM, send yourself reminders, create project management to-do’s…the sky’s the lim…”
   • [claimed-docs] “Trigger no-code automations with Zapier Sync with your CRM, send yourself reminders, create project management to-do’s…the sky’s the limit.”

   proof ↗⚑ flag

2. founderInvitees can reschedule or cancel from their confirmation, with my policies enforced and calendars updated everywhere

   weight 2 · round to Cal.com
   Cal.com✓fullclaimed8/10

   Cal.com documents reschedule/cancel flows directly on bookings (accepted/pending statuses), webhooks firing on BOOKING_RESCHEDULED/BOOKING_CANCELLED for downstream sync, calendar connections (Google, Apple, etc.) and conferencing apps that update everywhere, plus scheduling policies (schedules, round-robin configs, custom booking fields) enforced at booking time. This covers the core invitee self-service reschedule/cancel plus calendar sync and policy enforcement described in the docs. Missing for 10: no independent/hands-on confirmation that invitee-facing reschedule/cancel links actually work end-to-end in production, and no explicit documentation of the invitee-facing confirmation-page UI behavior itself (only API-level reschedule endpoint is evidenced).

   • [claimed-docs] “Reschedule a booking or seated booking.”
   • [claimed-docs] “Reschedule a booking or seated booking. Reschedulable booking statuses: - `accepted` — the confirmed booking is moved to the new start time.…”
   • [claimed-docs] “Reschedule a booking or seated booking. Reschedulable booking statuses: - `accepted` — the confirmed booking is moved to the new start time.…”
   • [claimed-docs] “Reschedulable booking statuses: - `accepted` — the confirmed booking is moved to the new start time. - `pending` — a booking awaitin…”
   • [claimed-docs] “BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING_REQUESTED - BOOKING_CANCELLED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED”
   • [claimed-docs] “triggers: type: array items: type: string enum: - BOOKING_CREATED - BOOKING_PAYMENT_INITIATED - BOOKING_PAID - BOOKING_RESCHEDULED - BOOKING…”
   • [claimed-docs] “Every Cal.com booking gets a location. By default that is Cal Video, and you can point it at Zoom, Microsoft Teams or Google Meet instead on…”
   • [claimed-docs] “Connect Zoom, Microsoft Teams or Google Meet to a user or a team”
   • [claimed-docs] “Google Calendar is a time management and scheduling service developed by Google. Allows users to create and edit events”
   • [claimed-docs] “Create a schedule for the authenticated user. The point of creating schedules is for event types to be available at specific times.”
   • [claimed-docs] “The point of creating schedules is for event types to be available at specific times.”
   • [claimed-docs] “**roundRobin**: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings (weights …”
   • [claimed-docs] “roundRobin: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings (weights togg…”

   proof ↗⚑ flag

   SavvyCal—none0/10

   The evidence pack contains no mention of invitee-initiated rescheduling or cancellation from a confirmation, nor any statement about policy enforcement or calendar sync on such changes. While this is a plausible feature for a scheduling product like SavvyCal, no documentation, webhook event, or feature page in the pack addresses it. Missing for 10: any mention of reschedule/cancel links in confirmations, policy enforcement on changes, or calendar update propagation across all attendees.

   ⚑ flag

3. founderEvery booking gets a video conference link automatically (Zoom, Google Meet, Teams, or native video)

   weight 2 · round to Cal.com
   Cal.com✓fullclaimed9/10

   Docs explicitly state every booking gets a location, defaulting to Cal Video, and can be pointed at Zoom, Microsoft Teams, or Google Meet once the app is connected — matching the story exactly. This is first-party documented core functionality with clear API support for conferencing app connections. Missing for 10: independent hands-on confirmation of the automatic link-generation flow in production use.

   • [claimed-docs] “Every Cal.com booking gets a location. By default that is Cal Video, and you can point it at Zoom, Microsoft Teams or Google Meet instead on…”
   • [claimed-docs] “Connect Zoom, Microsoft Teams or Google Meet to a user or a team”
   • [claimed-docs] “It powers one-on-one, group, round-robin, and collective scheduling, with routing forms, workflows, payments, native video, and an app store…”

   proof ↗⚑ flag

   SavvyCal~partialclaimed5/10

   Evidence shows automatic video link creation for specific providers (Zoom rooms, Google Meet links, Whereby rooms) tied to round-robin scheduling, implying similar support elsewhere, but there's no explicit mention of Teams integration or a general 'native video' option, and no confirmation this applies uniformly to all booking types beyond round-robin links. missing for 10: Microsoft Teams video link support, native/built-in video conferencing option, and confirmation this auto-generation applies to all booking link types (not just round-robin).

   • [claimed-docs] “Automatically create unique Zoom rooms for new events.”
   • [claimed-docs] “Add Meet links to your Google Calendar events.”
   • [claimed-docs] “Attach Whereby meeting rooms to calendar invites.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Cal.com
   Cal.com~partialprobed7/10

   Cal.com's API v2 covers most UI capabilities (bookings, event types, schedules, webhooks, routing, conferencing apps, managed users) and docs explicitly frame the API as AI-agent-ready, plus an MCP server exposes these operations to AI clients. However, evidence doesn't confirm full UI parity (e.g., no mention of API access to billing/compliance settings, app marketplace management, or admin/org settings via API), and an official OpenAPI spec could not be found (404s), making completeness hard to verify. missing for 10: confirmed full parity for admin/org-level settings and marketplace app configuration via API, a published OpenAPI schema, independent hands-on confirmation that all UI actions are API-reachable.

   • [claimed-docs] “Cal.com API v2 enables AI agents to: Check availability - Query available time slots for any user or team, Create bookings - Schedule meetin…”
   • [claimed-docs] “Cal.com API v2 enables AI agents to: **Check availability** - Query available time slots for any user or team * **Create bookings** - Schedu…”
   • [claimed-docs] “letting you manage bookings, event types, schedules, and more through natural language in any MCP-compatible client”
   • [claimed-docs] “For agents that can execute commands on a machine, use the official Cal.com CLI instead of calling the API directly.”
   • [claimed-docs] “a "managed user" is completely independent of a regular user account on cal.com, meaning you don't need your users to register on cal.com we…”
   • [claimed-docs] “Create a schedule for the authenticated user. The point of creating schedules is for event types to be available at specific times.”
   • [claimed-docs] “Every Cal.com booking gets a location. By default that is Cal Video, and you can point it at Zoom, Microsoft Teams or Google Meet instead on…”
   • [claimed-docs] “Retrieve the step-by-step routing trace for a booking identified by its UID. Shows how the booking was routed through routing forms, CRM loo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://cal.com/openapi.json, https://cal.com/swagger.json, https://cal.com/api/openapi.json, https:…”
   • [probe] “official MCP server documented at https://cal.com/docs/mcp-server”

   proof ↗⚑ flag

   SavvyCal~partialprobed3/10

   SavvyCal ships a documented REST API, OAuth/personal-access-token auth, webhooks, and a JS embed library, showing genuine API-based access to core scheduling functions, but there is no evidence the API covers the full breadth of UI features (round-robin, meeting polls, workflows, Stripe payment links, custom branding) and probes for an OpenAPI spec/llms.txt both 404, suggesting incomplete or undocumented API surface parity. missing for 10: evidence that advanced UI features (round robin, polls, workflows, payments, branding) are fully exposed via API, a public OpenAPI/schema reference, and independent confirmation of parity.

   • [claimed-docs] “The SavvyCal API adheres to REST conventions. Our API communicates in JSON format and uses OAuth access tokens to authenticate requests.”
   • [claimed-docs] “We offer several ways to integrate with our product, including a REST API, webhooks, and a JavaScript embed library.”
   • [claimed-docs] “OAuth 2.0: OAuth2 ... HTTP: Bearer Auth ... Personal access token authentication”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.savvycal.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.savvycal.com/openapi.json, https://developers.savvycal.com/swagger.json, https://…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Cal.com
   Cal.com!disputedcontradicted3/10

   Cal.com documents an open API (auth via key/OAuth) and an MIT-licensed self-host fork (Cal.diy) that could in principle let a user pull out their data and run independently, but there is no explicit 'export all my data' feature documented, and hands-on community reports directly contradict the openness/exit narrative: users say self-hosting the API isn't really possible ('there's no way to self-host the API... AGPL is a very restrictive license'), and more recent reports describe a bait-and-switch where Cal.diy/self-hosted docker images were pulled back and restricted to 'personal, non-production use,' with users abandoning self-hosting as a result. missing for 10: a documented data-export/portability feature, and confirmation that self-hosting reliably preserves full data ownership without restriction.

   • [github] “Cal.diy is 100% MIT-licensed with no proprietary "Enterprise Edition" features. It's designed for individuals and self-hosters who want full…”
   • [github] “Cal.diy is the community-driven, fully open-source scheduling platform — a fork of Cal.com with all enterprise/commercial code removed.”
   • [claimed-docs] “The Cal.com API has 3 authentication methods: 1. OAuth 2. API key 3. Platform (Deprecated)”
   • [claimed-docs] “Authentication to the API is performed via the Authorization header.”
   • [community] “Even if you self-host it, there's no way to self-host the API. You have to pay to use it. So you're just self-hosting the UI. They can chang…”
   • [community] “It’s curious what they said in the email they sent me about the OSS version... We will no longer provide public Docker images, so your team …”
   • [community] “From the docs, 'It is strictly recommended for personal, non-production use.' Wow what a 180 from just a year ago when their blog said on-pr…”
   • [community] “Not impossible though, I run a directory of open-source alternatives and rarely do you see what Cal.com did... a pure bait and switch like t…”
   • [community] “Their docs say cal.fyi won't have team features but my self hosted one does. They are a bit hacky... I think they also said they will stop p…”

   proof ↗⚑ flag

   SavvyCal—none0/10

   There is no evidence of a bulk data export feature or open-format data portability (e.g., CSV/JSON export of bookings, contacts, workflows) that would let a user take all their data and leave; the API exists for integration, not for full data export, and no explicit export/GDPR-style data-download feature is documented.

   ⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Cal.com
   Cal.com!disputedcontradicted5/10

   Cal.com does publish source under an open license — Cal.diy is documented as '100% MIT-licensed' with no proprietary Enterprise Edition and 'no license key required' (cal-com-gh-1/4/5), and llms.txt calls the 'self-hostable MIT edition' a core differentiator (cal-com-docs-43/48). However, hands-on community reports concretely contradict how open/usable that source is in practice: Cal.com stopped shipping public Docker images and now tells self-hosters 'It is strictly recommended for personal, non-production use' — a stated reversal from prior claims that self-hosting gave 'full ownership of infrastructure' (cal-com-comm-14, cal-com-comm-15, cal-com-comm-18, cal-com-comm-19), and the flagship cal.com repo itself is under a restrictive AGPL license per commenters (cal-com-comm-3). missing for 10: independent verification that the MIT Cal.diy source is fully buildable/production-usable, and reconciliation of the AGPL vs MIT licensing claims across the main repo and the fork.

   • [github] “Cal.diy is 100% MIT-licensed with no proprietary "Enterprise Edition" features. It's designed for individuals and self-hosters who want full…”
   • [github] “Cal.diy is **100% MIT-licensed** with no proprietary "Enterprise Edition" features. It's designed for individuals and self-hosters who want …”
   • [github] “No license key required — Everything works out of the box, no Cal.com account or license needed”
   • [claimed-docs] “For evaluators comparing against Calendly: Cal.com's differentiators are the self-hostable MIT edition (Cal.diy), API-first architecture, re…”
   • [claimed-docs] “Cal.com's differentiators are the self-hostable MIT edition (Cal.diy), API-first architecture, regulated-industry compliance, organization-s…”
   • [community] “Even if you self-host it, there's no way to self-host the API. You have to pay to use it. So you're just self-hosting the UI. They can chang…”
   • [community] “It’s curious what they said in the email they sent me about the OSS version... We will no longer provide public Docker images, so your team …”
   • [community] “From the docs, 'It is strictly recommended for personal, non-production use.' Wow what a 180 from just a year ago when their blog said on-pr…”
   • [community] “Not impossible though, I run a directory of open-source alternatives and rarely do you see what Cal.com did... a pure bait and switch like t…”
   • [community] “Their docs say cal.fyi won't have team features but my self hosted one does. They are a bit hacky... I think they also said they will stop p…”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal is a closed proprietary SaaS scheduling product; the only related evidence is a page mentioning unspecified 'contributions to the community,' not the product's own source code under an open license.

   • [claimed-docs] “Here are some of our contributions to the community”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Cal.com
   Cal.com!disputedcontradicted4/10

   Vendor and GitHub evidence claim Cal.diy is a 100% MIT-licensed, no-license-key-required fork designed for full self-hosting control, but multiple hands-on community reports concretely contradict this: users report the vendor stopped shipping public Docker images (requiring manual builds), official docs now say the OSS edition is 'strictly recommended for personal, non-production use,' and one commenter states you can't actually self-host the API without paying, calling it effectively 'self-hosting the UI' only, prompting accusations of a bait-and-switch from long-time self-hosters. A few users do report successfully self-hosting both API and DB, so the capability partially exists but is actively disputed. Missing for 10: a stable, vendor-provided production-grade self-hosting path (Docker images, full API) without contested community reports of regressions or non-production caveats.

   • [github] “Cal.diy is 100% MIT-licensed with no proprietary "Enterprise Edition" features. It's designed for individuals and self-hosters who want full…”
   • [github] “Cal.diy is the community-driven, fully open-source scheduling platform — a fork of Cal.com with all enterprise/commercial code removed.”
   • [github] “Cal.diy is **100% MIT-licensed** with no proprietary "Enterprise Edition" features. It's designed for individuals and self-hosters who want …”
   • [github] “No license key required — Everything works out of the box, no Cal.com account or license needed”
   • [community] “Even if you self-host it, there's no way to self-host the API. You have to pay to use it. So you're just self-hosting the UI. They can chang…”
   • [community] “the problem with cal.com 'open source' self-hosting is that they have made it quite difficult to run yourself... this actually doesn't provi…”
   • [community] “Also the docker compose in the repo is a mess and doesn't work... Clearly it seems to be a way to limit usage of the selfhosted version.”
   • [community] “I self host it, and I self host both the API and the database.”
   • [community] “It’s curious what they said in the email they sent me about the OSS version... We will no longer provide public Docker images, so your team …”
   • [community] “From the docs, 'It is strictly recommended for personal, non-production use.' Wow what a 180 from just a year ago when their blog said on-pr…”
   • [community] “As a former cal.com advocate, I am now going to be switching my two companies to cal.diy or a similar alternative and canceling my cal.com s…”
   • [community] “Not impossible though, I run a directory of open-source alternatives and rarely do you see what Cal.com did... a pure bait and switch like t…”
   • [community] “Their docs say cal.fyi won't have team features but my self hosted one does. They are a bit hacky... I think they also said they will stop p…”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal is a hosted SaaS scheduling product with no evidence of a self-hostable core; only an 'open-source contributions' page is mentioned, not a self-hostable server offering.

   • [claimed-docs] “Here are some of our contributions to the community”

   proof ↗⚑ flag

Pricing

1. founderThe free tier covers real individual scheduling — a usable booking link without a paid plan

   weight 2 · round to Cal.com
   Cal.com~partialcommunity6/10

   A Cal.com cofounder explicitly states in community discussion that everything that is Calendly's paid 'Pro' tier is free on Cal.com, and general docs describe core one-on-one scheduling/booking-link functionality that would presumably be available without payment; however, other community comments note certain paid add-ons (e.g., $29/mo premium usernames) exist, and there is no first-party pricing-page or plan-limits documentation in the pack confirming exactly what's free. Missing for 10: an official pricing/plan page from Cal.com detailing which core scheduling features are free, and independent hands-on confirmation of using a booking link fully free.

   • [community] “there are no trials anymore, everything that is PRO on calendly is free on cal.com (Cal.com cofounder response to pricing complaint)”
   • [claimed-docs] “Share a booking link, connect your calendars, and let people pick a time without the back-and-forth.”
   • [claimed-docs] “It powers one-on-one, group, round-robin, and collective scheduling, with routing forms, workflows, payments, native video, and an app store…”
   • [claimed-docs] “For evaluators comparing against Calendly: Cal.com's differentiators are the self-hostable MIT edition (Cal.diy), API-first architecture, re…”
   • [community] “I was curious about getting a premium username (@christina) but $29 a month... Love the idea, but $360 for a premium username. Nah. Not doin…”

   proof ↗⚑ flag

   SavvyCal—none0/10

   The evidence pack contains no mention of a free tier, free plan details, or what a basic booking link includes without payment; only feature and API docs are present, with no pricing-plan breakdown. Missing for 10: any documentation of a free plan's scope/limits, evidence that a usable booking link exists without payment, and confirmation of no-cost individual scheduling.

   ⚑ flag

2. founderPublished per-seat pricing tells me exactly what each tier costs and includes before I talk to sales

   weight 1 · round drawn
   Cal.com—none0/10

   The evidence pack contains no published pricing page, tier comparison, or per-seat cost breakdown for Cal.com; only scattered community mentions of a $29/month premium username add-on and a cofounder claim that 'everything PRO on Calendly is free,' neither of which constitutes documented per-seat tier pricing.

   • [community] “I was curious about getting a premium username (@christina) but $29 a month... Love the idea, but $360 for a premium username. Nah. Not doin…”
   • [community] “there are no trials anymore, everything that is PRO on calendly is free on cal.com (Cal.com cofounder response to pricing complaint)”
   • [community] “What does open source mean when you have to use a hosted solution and "premium" names cost 29 usd / month.”

   proof ↗⚑ flag

   SavvyCal—none0/10

   No evidence pack items reference pricing tiers, per-seat cost, or plan feature comparisons; only savvycal.com/pricing is mentioned once in passing (docs-59) without any pricing details. This is an applicable axis for a SaaS scheduling product, but no evidence shows published per-seat pricing.

   ⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Cal.com
   Cal.com~partialcommunity4/10

   Cal.com does not document a data-residency/region-selection feature for its hosted SaaS product, but it does offer self-hosting (Cal.diy, MIT-licensed, 'full control over their scheduling infrastructure') as the mechanism by which a user could choose where data lives, and llms.txt cites GDPR/CCPA/HIPAA compliance as differentiators. However community evidence shows self-hosting is troubled (no self-hostable API per cal-com-comm-3, docker image friction cal-com-comm-4/11, and a documented 'bait and switch' restricting Cal.diy to non-production use cal-com-comm-14/15), undercutting reliability of this as a residency-control path. Missing for 10: an explicit region/data-residency selection setting in the hosted product, first-party docs describing where data centers are located, and confirmation that self-hosting reliably satisfies residency requirements without the documented friction.

   • [github] “Cal.diy is 100% MIT-licensed with no proprietary "Enterprise Edition" features. It's designed for individuals and self-hosters who want full…”
   • [github] “Cal.diy is the community-driven, fully open-source scheduling platform — a fork of Cal.com with all enterprise/commercial code removed.”
   • [claimed-docs] “Compliance is a core differentiator. Cal.com supports HIPAA (with BAA available on organization/enterprise plans), SOC 2, ISO 27001, GDPR, a…”
   • [claimed-docs] “For evaluators comparing against Calendly: Cal.com's differentiators are the self-hostable MIT edition (Cal.diy), API-first architecture, re…”
   • [community] “Even if you self-host it, there's no way to self-host the API. You have to pay to use it. So you're just self-hosting the UI. They can chang…”
   • [community] “It’s curious what they said in the email they sent me about the OSS version... We will no longer provide public Docker images, so your team …”
   • [community] “From the docs, 'It is strictly recommended for personal, non-production use.' Wow what a 180 from just a year ago when their blog said on-pr…”

   proof ↗⚑ flag

   SavvyCal—none0/10

   No evidence anywhere in the pack of data residency options, regional storage selection, or data localization controls for SavvyCal; the evidence covers scheduling features and API auth only.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Cal.com—none0/10

   The evidence pack contains only a generic compliance claim (GDPR/CCPA/SOC2/HIPAA) with no concrete documentation of data retention policies, deletion APIs, or AI-agent-accessible controls to purge or manage stored booking/user data. No endpoint or workflow is shown for an AI-native user to actually control retention windows or trigger deletion.

   • [claimed-docs] “Compliance is a core differentiator. Cal.com supports HIPAA (with BAA available on organization/enterprise plans), SOC 2, ISO 27001, GDPR, a…”

   proof ↗⚑ flag

   SavvyCal—none0/10

   No evidence found addressing data retention policies, deletion controls, or privacy/data lifecycle management for SavvyCal; the evidence pack covers scheduling features, API auth, and webhooks only.

   ⚑ flag

Teams

1. sales leadOffer collective events that only show slots when every required host is free

   weight 2 · round to SavvyCal
   Cal.com~partialclaimed6/10

   Cal.com explicitly lists 'collective' as one of its native scheduling types alongside round-robin, group and one-on-one, and its slots API supports checking availability across multiple hosts (e.g. dynamic/username-based slot queries for '2 or more people'), which is the mechanism needed to only surface times when every host is free. However, the evidence pack shows detailed configuration docs (priority/weight/host groups/CRM fallback) only for round-robin, with no equivalent documented detail on collective-event host requirements or slot-intersection logic. Missing for 10: explicit collective-event configuration API docs, independent/hands-on confirmation that slots correctly reflect all-hosts-free logic.

   • [claimed-docs] “It powers one-on-one, group, round-robin, and collective scheduling, with routing forms, workflows, payments, native video, and an app store…”
   • [claimed-docs] “There are 4 ways to get available slots for event type of an individual user: 1. By event type id. ... 4. By usernames only (used for dynami…”
   • [claimed-docs] “roundRobin: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings”
   • [claimed-docs] “Returns the scheduling configuration for a team event type.”

   proof ↗⚑ flag

   SavvyCal✓fullclaimed8/10

   SavvyCal explicitly documents collective scheduling links that show combined availability across multiple teammates, only surfacing slots where the whole group is free ('Show combined availability for you and any number of teammates that allow recipients to book a time with your selected group'; 'Combine your availability with multiple colleagues on scheduling links'), distinct from its round-robin (any-available-host) mode. Missing for 10: independent/hands-on corroboration beyond vendor marketing pages and explicit confirmation of 'required host' logic vs optional overlay.

   • [claimed-docs] “Show combined availability for you and any number of teammates that allow recipients to book a time with your selected group.”
   • [claimed-docs] “Combine your availability with multiple colleagues on scheduling links.”
   • [claimed-docs] “Show collective availability to book any available team member.”
   • [claimed-docs] “Show combined availability for your whole team and automatically route each booked meeting to the right person.”

   proof ↗⚑ flag

2. sales leadInbound meetings distribute across my team round-robin, with weighting or priority so load stays fair

   weight 2 · round to Cal.com
   Cal.com✓fullclaimed8/10

   Cal.com's API documents full round-robin scheduling configuration with per-host priority, weight, group assignment, weights toggle, lead threshold, no-show calculations, and CRM fallback (cal-com-docs-15/25/41), plus llms.txt confirms round-robin scheduling as a core product feature (cal-com-docs-28). This directly matches the sales-lead need for fair, weighted lead distribution. Missing for 10: independent/hands-on verification of round-robin fairness in practice and no UI-level walkthrough evidence beyond API docs.

   • [claimed-docs] “roundRobin: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings”
   • [claimed-docs] “roundRobin: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings (weights togg…”
   • [claimed-docs] “**roundRobin**: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings (weights …”
   • [claimed-docs] “It powers one-on-one, group, round-robin, and collective scheduling, with routing forms, workflows, payments, native video, and an app store…”
   • [claimed-docs] “Returns the scheduling configuration for a team event type.”
   • [claimed-docs] “The response varies by the event type's scheduling type, and non-team event types are rejected.”

   proof ↗⚑ flag

   SavvyCal~partialclaimed6/10

   SavvyCal has dedicated round-robin/pooling features that distribute meetings across team members either by cycling (equal distribution) or random selection for max availability, explicitly marketed for sales use cases. However, there is no evidence of configurable weighting or priority levels among team members (e.g., unequal load ratios) beyond binary equal/random distribution. Missing for 10: explicit weighted/priority-based distribution controls, admin-configurable ratios per rep, and independent confirmation of fairness enforcement over time.

   • [claimed-docs] “Show combined availability for your whole team and automatically route each booked meeting to the right person.”
   • [claimed-docs] “The choice is yours — randomly select who the meeting gets booked with for maximum availability or cycle through team members for equal dist…”
   • [claimed-docs] “Automatically distribute meetings across team members fairly.”
   • [claimed-docs] “Round robin pooling Automatically distribute meetings across team members fairly.”
   • [claimed-docs] “Distribute meetings across a pool of organizers. Perfect for sales and customer support.”
   • [claimed-docs] “Team members can set custom availability for each round robin scheduling link or default to their preset work hours.”

   proof ↗⚑ flag

3. sales leadA routing form qualifies invitees and sends them to the right person or team based on their answers

   weight 1 · round to Cal.com
   Cal.com✓fullclaimed6/10

   Cal.com's docs explicitly list routing forms as a core feature (docs-28) and expose a dedicated API for tracing 'how the booking was routed through routing forms, CRM lookups, and host selection logic' (cal-com-docs-8), confirming invitee answers drive routing decisions. Team scheduling configs also support round-robin host selection with priority/weight/lead-threshold/CRM fallback (cal-com-docs-15/25/41), reinforcing routing-to-right-person capability. Missing for 10: no detailed documentation of the routing form builder UI itself (question types, conditional branching rules) or independent/hands-on confirmation of routing form setup and accuracy.

   • [claimed-docs] “Retrieve the step-by-step routing trace for a booking identified by its UID. Shows how the booking was routed through routing forms, CRM loo…”
   • [claimed-docs] “It powers one-on-one, group, round-robin, and collective scheduling, with routing forms, workflows, payments, native video, and an app store…”
   • [claimed-docs] “roundRobin: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings”
   • [claimed-docs] “roundRobin: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings (weights togg…”
   • [claimed-docs] “**roundRobin**: Full configuration including hosts with priority, weight, and group assignment, host groups, and advanced settings (weights …”

   proof ↗⚑ flag

   SavvyCal—none0/10

   SavvyCal documents round-robin and collective team scheduling that automatically distributes meetings across team members, but there is no evidence of a routing/qualification form that asks invitees questions and branches them to different people or teams based on their answers. Missing for 10: any mention of conditional routing forms, question-based qualification logic, or answer-driven assignment to specific reps/teams.

   • [claimed-docs] “Show combined availability for your whole team and automatically route each booked meeting to the right person.”
   • [claimed-docs] “The choice is yours — randomly select who the meeting gets booked with for maximum availability or cycle through team members for equal dist…”
   • [claimed-docs] “Automatically distribute meetings across team members fairly.”
   • [claimed-docs] “Distribute meetings across a pool of organizers. Perfect for sales and customer support.”

   proof ↗⚑ flag