Cal.com

1. 调研缘由

预约产品的难点不只是展示可选时间，还包括身份、日历、团队规则、时区和外部系统之间的协调。Cal.com 的官方 API v2 文档把 OAuth、API key、团队、组织、预约和可用时段等作为独立能力组织起来。[S1]

2. 简介与产品工作流

对集成方而言，常见路径是先选择 OAuth 或 API key 完成认证，再读取用户、日历和事件类型信息，最后根据 schedules、slots 和 bookings 接口构建预约体验。[S1] 文档明确列出三种认证方式，并建议构建集成或应用时优先使用 OAuth；API key 适合较直接的服务端调用。[S1]

这意味着 Cal.com 可以作为面向最终用户的预约界面，也可以作为嵌入其他产品的调度后端。实际权限范围、速率限制和令牌管理仍需随目标接口逐项确认。

3. 团队与资本背景

Cal.com 公开维护其代码仓库，并以 AGPL-3.0 许可证发布仓库中的开源部分。[S2] 本篇不以融资信息或媒体估值定义其产品价值，因为这些信息既非本篇的核心能力证据，也会快速变化。

4. 技术基础与生态位

API v2 把 bookings、calendars、schedules、slots、out-of-office 和组织／团队端点拆分出来。[S1] 这种划分说明它并非单一的“约个时间”页面，而是将调度规则和对象提供给应用集成。开源仓库则让开发者可查看代码、贡献方式和许可证边界。[S2]

5. 市场与外部信号

官方文档为 OAuth 合作方、团队和组织场景提供独立入口，并提到 API key 管理和 rate limits。[S1] 这反映它面向的不只是个人日程，而是需要把预约纳入产品、销售、支持或内部流程的开发者和团队。

6. 公开评价与主要分歧

**可取之处：**API、OAuth、日历和可用时段能力在官方文档中有清晰的资源边界，便于集成方按需实现。[S1]

**主要分歧：**开源代码并不自动意味着所有托管能力、支持等级或商业功能都具有同样的开放边界。部署者还要处理日历授权、令牌存储、时区规则和隐私合规。

7. 同类对比

维度	Cal.com	单点预约 SaaS	自建调度服务
集成接口	提供 OAuth、API key 与平台相关接口。[S1]	通常以成品页面和集成为主。	可完全定制，但要自建对象与认证。
调度对象	文档覆盖预约、日历、排班和 slots。[S1]	侧重标准预约流程。	由团队自行建模。
代码可见性	仓库公开且标明许可证。[S2]	多数不公开实现。	完全由团队维护。

对比只描述部署和接口选择，不对服务稳定性或成本作未验证判断。

8. 信息缺口与后续观察

生产接入前应核对目标 API 的版本状态、rate limits、OAuth 审核流程、数据保留和日历供应商支持范围；若自托管，还要确认许可证义务及运维成本。

9. 归纳洞察 ★

调度系统的竞争力常常藏在边界条件里：谁能安全地拿到日历权限，谁能把规则转换成可用时段，谁又能让这些对象被别的产品可靠调用。对开发者而言，评估重点应从预约页面移向 API 的对象模型和身份边界。

10. 来源与更新时间

• 信息截至(as_of): 2026-08-01
• 最后复查(last_checked): 2026-08-01