尧图网站建设 
Cal.diy 集成 Make 自动化平台从 API Key 生成到 Webhook 订阅的完整实战指南【免费下载链接】cal.diyScheduling infrastructure for absolutely everyone.项目地址: https://gitcode.com/GitHub_Trending/ca/cal.diyCal.diy 提供了官方的 Make 应用用于将日程事件与 Make 这一可视化自动化平台打通当有预订被创建、改期、取消或会议结束时Cal.diy 会主动把事件推送到你编排好的 Make 场景Scenario中你还可以通过 List Bookings 模块拉取全部预订数据。本文将以应用目录App Store中的 Make 集成为核心完整讲解安装配置、API Key 管理、Make 侧连接与场景搭建以及底层 Webhook 订阅机制的源码实现读完即可在自建部署或云端实例上跑通一套预订事件驱动自动化的实战方案。一、Make 集成是什么能力总览Make 应用在 Cal.diy 应用商店中的定位是automation自动化类别其配置定义在 packages/app-store/make/config.json{ name: Make, slug: make, type: make_automation, logo: icon.svg, variant: automation, categories: [automation], publisher: aar2dee2, description: From tasks and workflows to apps and systems, build and automate anything in one powerful visual platform., isOAuth: false }从 DESCRIPTION.md 中可以看到该集成官方定义的能力边界事件触发Triggers预订被创建Booking Created、预订被删除Booking Deleted、预订被改期Booking Rescheduled、会议已结束Meeting Ended四类事件发生时自动触发 Make 场景数据拉取Module通过 List Bookings 模块获取当前账号下的全部预订数据连接复用Connection在 Make 中只需创建一次连接包含 Cal 部署 URL 与 API Key所有 Webhook 场景均可复用该连接。该集成还提供一个Setup 页面/apps/make/setup用于生成和管理 API Key。如果安装后丢失了 API Key随时可以回到 Setup 页面重新生成一把新 Key这是官方在 DESCRIPTION.md 中特别强调的兜底能力。注意config.json中明确标注了 Dont modify slug——make这个 slug 以及make_automation类型是整套 API 路由、订阅逻辑与凭证查找的契约修改会导致集成失效。二、安装与初始化从应用商店到 Setup 页面2.1 安装应用并生成 API Key在 Cal.diy 的应用商店中找到Make应用并完成安装。安装动作由 packages/app-store/make/api/add.ts 处理其核心逻辑如下const handler: AppDeclarativeHandler { appType: appConfig.type, // make_automation variant: appConfig.variant, // automation slug: appConfig.slug, // make supportsMultipleInstalls: false, // 每个账号仅允许安装一次 handlerType: add, redirect: { newTab: true, url: /apps/make/setup, }, createCredential: ({ appType, user, slug, teamId }) createDefaultInstallation({ appType, user: user, slug, key: {}, teamId }), };几个值得注意的实现细节supportsMultipleInstalls: falseMake 集成不支持重复安装同一个账号只能维护一套凭证安装成功后自动跳转到/apps/make/setup在新标签页打开引导用户立即生成 API KeycreateDefaultInstallation创建的是空凭证key: {}真正的 API Key 需要在 Setup 页面上手动生成。2.2 Setup 页面与 API Key 生命周期Setup 页面的服务端逻辑位于 packages/app-store/make/pages/setup/_getServerSideProps.tsxexport const getServerSideProps async (ctx: GetServerSidePropsContext) { const notFound { notFound: true } as const; if (typeof ctx.params?.slug ! string) return notFound; let inviteLink ; const appKeys await getAppKeysFromSlug(make); if (typeof appKeys.invite_link string) inviteLink appKeys.invite_link; return { props: { inviteLink } }; };页面会通过getAppKeysFromSlug(make)从应用密钥配置中读取invite_linkMake 应用邀请链接并将其注入到前端页面中。这意味着每个部署实例可以通过配置invite_link来指定自己的 Make 应用邀请入口Setup 页面会动态渲染这个链接。在界面操作上Setup 页面依次引导用户完成 5 个步骤登录 Make 账号并创建一个新 Scenario场景在 Make 中选择 Cal.diy 作为 Trigger触发应用并选择要监听的事件选择账号并填入本页生成的唯一 API Key测试 Trigger 是否可用完成配置。点击 Generate API key 后会展示唯一的 API Key形如cal_16...并提示Copy this API key and save it somewhere safe. If you lose this key you have to generate a new one.——该 Key 只展示一次丢失后只能重新生成因此务必在复制后妥善保存。三、在 Make 中配置连接与场景安装完成后需要在 Make 侧完成连接创建与场景编排完整的官方步骤记录在 packages/app-store/make/README.md从 Cal 应用商店安装 Make 应用并生成 API Key复制保存在 Cal 管理后台/admin/apps/automation中将 Make 的invite_link配置为你的 Make 应用邀请链接README 中给出了官方示例https://www.make.com/en/hq/app-invitation/6cb2772b61966508dd8f414ba3b44510以启用该应用注册/登录 Make 账号在侧边栏进入Scenarios点击Create a new scenario创建新场景在应用列表中搜索Cal.diy从触发器列表中选择Booking Created预订创建、Booking Deleted预订删除、Booking Rescheduled预订改期、Meeting Ended会议结束创建connection连接时需要填写 Cal 部署 URL 与上面生成的 API Key。连接只需创建一次所有 Webhook 场景都可复用在 Make 中为期望的事件配置 Webhook若要删除 Webhook进入 Make 左侧边栏的Webhooks选中要删除的 Webhook 并点击delete。3.1 本地开发与自建部署的特殊约束README 特别强调了一条限制Localhost URL 不能作为 API 端点的 Base URL 使用。也就是说如果你在本地运行 Cal.diy例如localhost:3000Make 侧无法访问你的回调地址也就无法完成连接测试与事件推送。官方给出的解决方案是使用 ngrok 建立隧道注册 ngrok 账号下载 ngrok 并启动一条指向本地 Cal.diy 实例的隧道ngrok http 3000把得到的 forwarding URL 作为 API 端点的 Base URL在 Make 创建Connection时将 ngrok 转发 URL 作为 Cal 部署 URL 填写。同理自建部署在云服务器上时也必须使用公网可达的 HTTPS 域名作为部署 URL而不能填写内网地址或 localhost。四、底层 APIMake 集成的 4 个订阅端点Make 应用暴露的 API 路由定义在 packages/app-store/make/api/index.tsexport { default as add } from ./add; export { default as listBookings } from ./subscriptions/listBookings; export { default as deleteSubscription } from ./subscriptions/deleteSubscription; export { default as addSubscription } from ./subscriptions/addSubscription; export { default as me } from ./subscriptions/me;所有端点除add安装处理外都遵循同一个鉴权模型通过findValidApiKey(apiKey, make)校验请求携带的 API Key且该 Key 必须属于make应用校验失败统一返回401。这一查找逻辑位于packages/app-store/_utils/findValidApiKey它是 Make 侧所有请求的第一道防线。4.1 创建订阅addSubscriptionpackages/app-store/make/api/subscriptions/addSubscription.ts 对应POST请求用于注册一个 Webhook 订阅async function handler(req: NextApiRequest, res: NextApiResponse) { const apiKey req.query.apiKey as string; if (!apiKey) { return res.status(401).json({ message: No API key provided }); } const validKey await findValidApiKey(apiKey, make); if (!validKey) { return res.status(401).json({ message: API key not valid }); } const { subscriberUrl, triggerEvent } req.body; const createAppSubscription await addSubscription({ appApiKey: validKey, triggerEvent: triggerEvent, subscriberUrl: subscriberUrl, appId: make, }); if (!createAppSubscription) { return res.status(500).json({ message: Could not create subscription. }); } res.status(200).json(createAppSubscription); }请求参数由两部分组成查询参数apiKey应用 API Key请求体subscriberUrlMake 侧的回调/Webhook URL与triggerEvent要监听的事件。addSubscription最终委托给calcom/features/webhooks/lib/scheduleTrigger中导出的同名工具函数以appId: make作为应用标识创建订阅。也就是说Make 集成在底层复用的是 Cal.diy 统一的 Webhook 调度schedule trigger基础设施而不是一套私有实现——这保证了与其它 Webhook 消费者一致的事件投递行为。4.2 拉取预订listBookingspackages/app-store/make/api/subscriptions/listBookings.ts 对应GET请求对应 Make 中的 List Bookings 模块const bookings await listBookings(validKey); if (!bookings) { return res.status(500).json({ message: Unable to get bookings. }); } if (bookings.length 0) { const requested validKey.teamId ? teamId: ${validKey.teamId} : userId: ${validKey.userId}; return res.status(404).json({ message: There are no bookings to retrieve, please create a booking first. Requested: \${requested}\, }); } res.status(201).json(bookings);实现细节值得注意该端点按API Key 归属的用户或团队维度返回预订数据——从返回信息可以看出查询作用域由凭证的teamId团队或userId用户决定当该作用域下没有任何预订时返回404并附带明确的提示信息引导用户先创建预订成功时返回201与完整的预订列表。这意味着在 Make 场景中List Bookings 模块拉到的数据始终是与当前连接凭证绑定的账号下的预订多租户场景下每个连接各自隔离。4.3 删除订阅deleteSubscriptionpackages/app-store/make/api/subscriptions/deleteSubscription.ts 对应DELETE请求用于删除一个已存在的 Webhook 订阅。它与创建端点的差异在于多了一个id查询参数使用 zod 的querySchema做参数校验const querySchema z.object({ apiKey: z.string(), id: z.string(), });删除成功后返回204无内容并附带确认消息Subscription is deleted.。这与 Make 侧在 Webhooks 面板中手动删除 Webhook的操作是两条并行的删除路径——通过 API 删除的订阅会走 Cal.diy 的deleteSubscription调度逻辑确保 Webhook 注册被彻底清理。4.4 校验当前用户mepackages/app-store/make/api/subscriptions/me.ts 对应GET请求用于校验 API Key 并返回其所属用户的用户名const user await prisma.user.findFirst({ where: { id: validKey.userId }, select: { username: true }, }); res.status(201).json(user);在 Make 创建 Connection 的过程中Make 侧会用这个端点校验Cal 部署 URL API Key组合是否有效并据此识别当前连接对应的用户账号。五、实战用 Make 把预订数据写入 Google Sheets结合 packages/app-store/make 目录下的官方截图1.png、2.png、3.png、4.png、5.png与 README 步骤一个典型的预订事件 → 表格记录场景可以这样搭建在 Cal.diy 生成 API Key进入/apps/make/setup点击 Generate API key复制形如cal_...的唯一 Key在 Make 中创建场景并添加触发器新建 Scenario搜索并选择Cal.diy应用从 Booking Created / Booking Deleted / Booking Rescheduled / Meeting Ended 四个触发器中选择目标事件创建 Connection在触发器模块上点击 Create a connection填入 Connection name如My apiKey connection、API Key以及 Cal 部署 URL自建/本地环境使用 ngrok 转发 URL例如https://xxxx-xx-xx.ngrok-free.app编排下游模块将触发器的输出连接到目标应用如 Google Sheets做字段映射。官方示例映射为Meeting Name ← 33.Title、Meeting Type ← 33.Event Type: title、Attendee ← 33.Attendees[].email、Start Time ← 33.startTime、End Time ← 33.endTime、Status ← 33.status运行验证触发一次真实预订或测试 Trigger场景运行成功后Cal.diy 模块的输出会携带完整的预订数据Title、Start Time、End Time、Status 等下游表格即被正确写入。在这个流程中33前缀代表触发器模块的输出引用字段名Title、Event Type: title、Attendees[].email、startTime、endTime、status与 listBookings.ts 返回的预订对象结构对应这是 Make 模块能正确解析数据的前提。六、常见问题与排查建议问题现象可能原因处理建议安装后跳转 Setup 页但无法生成 Key应用凭证初始化异常确认安装流程走完createDefaultInstallation必要时卸载重装注意supportsMultipleInstalls: false需先移除旧安装API Key 丢失Key 仅在生成时展示一次回到/apps/make/setup重新生成新 Key并在 Make 中更新 Connection 配置Connection 创建失败Base URL 不可达或 Key 无效确认部署 URL 是公网可访问的 HTTPS 地址本地环境使用 ngrok 隧道重新校验 API Key401 No API key provided/API key not valid请求未携带 Key或 Key 不属于 make 应用检查请求中apiKey查询参数是否与凭证一致且该 Key 是通过 Make 应用生成的404 There are no bookings to retrieve当前凭证作用域下还没有预订先在该账号下创建一笔预订再调用 List Bookings 模块Localhost 无法作为 Base URLMake 无法访问内网地址使用 ngrok 等隧道工具将本地实例暴露为公网 HTTPS 地址七、总结Cal.diy 的 Make 集成是一套安装即用的自动化入口用户侧只需完成生成 API Key → 在 Make 中创建连接与场景两步即可把预订生命周期中的创建、删除、改期、会议结束四类事件实时推送到任意自动化流程中开发者侧则可直接复用 packages/app-store/make/api 下基于scheduleTrigger与findValidApiKey构建的订阅/查询/删除/校验四类端点理解appId与 API Key 绑定这一鉴权模型就能在此基础上扩展出更多面向自动化平台的集成。无论是云端实例还是自建部署这套集成都能让预订即数据、事件即自动化成为现实。【免费下载链接】cal.diyScheduling infrastructure for absolutely everyone.项目地址: https://gitcode.com/GitHub_Trending/ca/cal.diy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cal.diy 集成 Make 自动化平台：从 API Key 生成到 Webhook 订阅的完整实战指南
Cal.diy 集成 Make 自动化平台从 API Key 生成到 Webhook 订阅的完整实战指南【免费下载链接】cal.diyScheduling infrastructure for absolutely everyone.项目地址: https://gitcode.com/GitHub_Trending/ca/cal.diyCal.diy 提供了官方的 Make 应用用于将日程事件与 Make 这一可视化自动化平台打通当有预订被创建、改期、取消或会议结束时Cal.diy 会主动把事件推送到你编排好的 Make 场景Scenario中你还可以通过 List Bookings 模块拉取全部预订数据。本文将以应用目录App Store中的 Make 集成为核心完整讲解安装配置、API Key 管理、Make 侧连接与场景搭建以及底层 Webhook 订阅机制的源码实现读完即可在自建部署或云端实例上跑通一套预订事件驱动自动化的实战方案。一、Make 集成是什么能力总览Make 应用在 Cal.diy 应用商店中的定位是automation自动化类别其配置定义在 packages/app-store/make/config.json{ name: Make, slug: make, type: make_automation, logo: icon.svg, variant: automation, categories: [automation], publisher: aar2dee2, description: From tasks and workflows to apps and systems, build and automate anything in one powerful visual platform., isOAuth: false }从 DESCRIPTION.md 中可以看到该集成官方定义的能力边界事件触发Triggers预订被创建Booking Created、预订被删除Booking Deleted、预订被改期Booking Rescheduled、会议已结束Meeting Ended四类事件发生时自动触发 Make 场景数据拉取Module通过 List Bookings 模块获取当前账号下的全部预订数据连接复用Connection在 Make 中只需创建一次连接包含 Cal 部署 URL 与 API Key所有 Webhook 场景均可复用该连接。该集成还提供一个Setup 页面/apps/make/setup用于生成和管理 API Key。如果安装后丢失了 API Key随时可以回到 Setup 页面重新生成一把新 Key这是官方在 DESCRIPTION.md 中特别强调的兜底能力。注意config.json中明确标注了 Dont modify slug——make这个 slug 以及make_automation类型是整套 API 路由、订阅逻辑与凭证查找的契约修改会导致集成失效。二、安装与初始化从应用商店到 Setup 页面2.1 安装应用并生成 API Key在 Cal.diy 的应用商店中找到Make应用并完成安装。安装动作由 packages/app-store/make/api/add.ts 处理其核心逻辑如下const handler: AppDeclarativeHandler { appType: appConfig.type, // make_automation variant: appConfig.variant, // automation slug: appConfig.slug, // make supportsMultipleInstalls: false, // 每个账号仅允许安装一次 handlerType: add, redirect: { newTab: true, url: /apps/make/setup, }, createCredential: ({ appType, user, slug, teamId }) createDefaultInstallation({ appType, user: user, slug, key: {}, teamId }), };几个值得注意的实现细节supportsMultipleInstalls: falseMake 集成不支持重复安装同一个账号只能维护一套凭证安装成功后自动跳转到/apps/make/setup在新标签页打开引导用户立即生成 API KeycreateDefaultInstallation创建的是空凭证key: {}真正的 API Key 需要在 Setup 页面上手动生成。2.2 Setup 页面与 API Key 生命周期Setup 页面的服务端逻辑位于 packages/app-store/make/pages/setup/_getServerSideProps.tsxexport const getServerSideProps async (ctx: GetServerSidePropsContext) { const notFound { notFound: true } as const; if (typeof ctx.params?.slug ! string) return notFound; let inviteLink ; const appKeys await getAppKeysFromSlug(make); if (typeof appKeys.invite_link string) inviteLink appKeys.invite_link; return { props: { inviteLink } }; };页面会通过getAppKeysFromSlug(make)从应用密钥配置中读取invite_linkMake 应用邀请链接并将其注入到前端页面中。这意味着每个部署实例可以通过配置invite_link来指定自己的 Make 应用邀请入口Setup 页面会动态渲染这个链接。在界面操作上Setup 页面依次引导用户完成 5 个步骤登录 Make 账号并创建一个新 Scenario场景在 Make 中选择 Cal.diy 作为 Trigger触发应用并选择要监听的事件选择账号并填入本页生成的唯一 API Key测试 Trigger 是否可用完成配置。点击 Generate API key 后会展示唯一的 API Key形如cal_16...并提示Copy this API key and save it somewhere safe. If you lose this key you have to generate a new one.——该 Key 只展示一次丢失后只能重新生成因此务必在复制后妥善保存。三、在 Make 中配置连接与场景安装完成后需要在 Make 侧完成连接创建与场景编排完整的官方步骤记录在 packages/app-store/make/README.md从 Cal 应用商店安装 Make 应用并生成 API Key复制保存在 Cal 管理后台/admin/apps/automation中将 Make 的invite_link配置为你的 Make 应用邀请链接README 中给出了官方示例https://www.make.com/en/hq/app-invitation/6cb2772b61966508dd8f414ba3b44510以启用该应用注册/登录 Make 账号在侧边栏进入Scenarios点击Create a new scenario创建新场景在应用列表中搜索Cal.diy从触发器列表中选择Booking Created预订创建、Booking Deleted预订删除、Booking Rescheduled预订改期、Meeting Ended会议结束创建connection连接时需要填写 Cal 部署 URL 与上面生成的 API Key。连接只需创建一次所有 Webhook 场景都可复用在 Make 中为期望的事件配置 Webhook若要删除 Webhook进入 Make 左侧边栏的Webhooks选中要删除的 Webhook 并点击delete。3.1 本地开发与自建部署的特殊约束README 特别强调了一条限制Localhost URL 不能作为 API 端点的 Base URL 使用。也就是说如果你在本地运行 Cal.diy例如localhost:3000Make 侧无法访问你的回调地址也就无法完成连接测试与事件推送。官方给出的解决方案是使用 ngrok 建立隧道注册 ngrok 账号下载 ngrok 并启动一条指向本地 Cal.diy 实例的隧道ngrok http 3000把得到的 forwarding URL 作为 API 端点的 Base URL在 Make 创建Connection时将 ngrok 转发 URL 作为 Cal 部署 URL 填写。同理自建部署在云服务器上时也必须使用公网可达的 HTTPS 域名作为部署 URL而不能填写内网地址或 localhost。四、底层 APIMake 集成的 4 个订阅端点Make 应用暴露的 API 路由定义在 packages/app-store/make/api/index.tsexport { default as add } from ./add; export { default as listBookings } from ./subscriptions/listBookings; export { default as deleteSubscription } from ./subscriptions/deleteSubscription; export { default as addSubscription } from ./subscriptions/addSubscription; export { default as me } from ./subscriptions/me;所有端点除add安装处理外都遵循同一个鉴权模型通过findValidApiKey(apiKey, make)校验请求携带的 API Key且该 Key 必须属于make应用校验失败统一返回401。这一查找逻辑位于packages/app-store/_utils/findValidApiKey它是 Make 侧所有请求的第一道防线。4.1 创建订阅addSubscriptionpackages/app-store/make/api/subscriptions/addSubscription.ts 对应POST请求用于注册一个 Webhook 订阅async function handler(req: NextApiRequest, res: NextApiResponse) { const apiKey req.query.apiKey as string; if (!apiKey) { return res.status(401).json({ message: No API key provided }); } const validKey await findValidApiKey(apiKey, make); if (!validKey) { return res.status(401).json({ message: API key not valid }); } const { subscriberUrl, triggerEvent } req.body; const createAppSubscription await addSubscription({ appApiKey: validKey, triggerEvent: triggerEvent, subscriberUrl: subscriberUrl, appId: make, }); if (!createAppSubscription) { return res.status(500).json({ message: Could not create subscription. }); } res.status(200).json(createAppSubscription); }请求参数由两部分组成查询参数apiKey应用 API Key请求体subscriberUrlMake 侧的回调/Webhook URL与triggerEvent要监听的事件。addSubscription最终委托给calcom/features/webhooks/lib/scheduleTrigger中导出的同名工具函数以appId: make作为应用标识创建订阅。也就是说Make 集成在底层复用的是 Cal.diy 统一的 Webhook 调度schedule trigger基础设施而不是一套私有实现——这保证了与其它 Webhook 消费者一致的事件投递行为。4.2 拉取预订listBookingspackages/app-store/make/api/subscriptions/listBookings.ts 对应GET请求对应 Make 中的 List Bookings 模块const bookings await listBookings(validKey); if (!bookings) { return res.status(500).json({ message: Unable to get bookings. }); } if (bookings.length 0) { const requested validKey.teamId ? teamId: ${validKey.teamId} : userId: ${validKey.userId}; return res.status(404).json({ message: There are no bookings to retrieve, please create a booking first. Requested: \${requested}\, }); } res.status(201).json(bookings);实现细节值得注意该端点按API Key 归属的用户或团队维度返回预订数据——从返回信息可以看出查询作用域由凭证的teamId团队或userId用户决定当该作用域下没有任何预订时返回404并附带明确的提示信息引导用户先创建预订成功时返回201与完整的预订列表。这意味着在 Make 场景中List Bookings 模块拉到的数据始终是与当前连接凭证绑定的账号下的预订多租户场景下每个连接各自隔离。4.3 删除订阅deleteSubscriptionpackages/app-store/make/api/subscriptions/deleteSubscription.ts 对应DELETE请求用于删除一个已存在的 Webhook 订阅。它与创建端点的差异在于多了一个id查询参数使用 zod 的querySchema做参数校验const querySchema z.object({ apiKey: z.string(), id: z.string(), });删除成功后返回204无内容并附带确认消息Subscription is deleted.。这与 Make 侧在 Webhooks 面板中手动删除 Webhook的操作是两条并行的删除路径——通过 API 删除的订阅会走 Cal.diy 的deleteSubscription调度逻辑确保 Webhook 注册被彻底清理。4.4 校验当前用户mepackages/app-store/make/api/subscriptions/me.ts 对应GET请求用于校验 API Key 并返回其所属用户的用户名const user await prisma.user.findFirst({ where: { id: validKey.userId }, select: { username: true }, }); res.status(201).json(user);在 Make 创建 Connection 的过程中Make 侧会用这个端点校验Cal 部署 URL API Key组合是否有效并据此识别当前连接对应的用户账号。五、实战用 Make 把预订数据写入 Google Sheets结合 packages/app-store/make 目录下的官方截图1.png、2.png、3.png、4.png、5.png与 README 步骤一个典型的预订事件 → 表格记录场景可以这样搭建在 Cal.diy 生成 API Key进入/apps/make/setup点击 Generate API key复制形如cal_...的唯一 Key在 Make 中创建场景并添加触发器新建 Scenario搜索并选择Cal.diy应用从 Booking Created / Booking Deleted / Booking Rescheduled / Meeting Ended 四个触发器中选择目标事件创建 Connection在触发器模块上点击 Create a connection填入 Connection name如My apiKey connection、API Key以及 Cal 部署 URL自建/本地环境使用 ngrok 转发 URL例如https://xxxx-xx-xx.ngrok-free.app编排下游模块将触发器的输出连接到目标应用如 Google Sheets做字段映射。官方示例映射为Meeting Name ← 33.Title、Meeting Type ← 33.Event Type: title、Attendee ← 33.Attendees[].email、Start Time ← 33.startTime、End Time ← 33.endTime、Status ← 33.status运行验证触发一次真实预订或测试 Trigger场景运行成功后Cal.diy 模块的输出会携带完整的预订数据Title、Start Time、End Time、Status 等下游表格即被正确写入。在这个流程中33前缀代表触发器模块的输出引用字段名Title、Event Type: title、Attendees[].email、startTime、endTime、status与 listBookings.ts 返回的预订对象结构对应这是 Make 模块能正确解析数据的前提。六、常见问题与排查建议问题现象可能原因处理建议安装后跳转 Setup 页但无法生成 Key应用凭证初始化异常确认安装流程走完createDefaultInstallation必要时卸载重装注意supportsMultipleInstalls: false需先移除旧安装API Key 丢失Key 仅在生成时展示一次回到/apps/make/setup重新生成新 Key并在 Make 中更新 Connection 配置Connection 创建失败Base URL 不可达或 Key 无效确认部署 URL 是公网可访问的 HTTPS 地址本地环境使用 ngrok 隧道重新校验 API Key401 No API key provided/API key not valid请求未携带 Key或 Key 不属于 make 应用检查请求中apiKey查询参数是否与凭证一致且该 Key 是通过 Make 应用生成的404 There are no bookings to retrieve当前凭证作用域下还没有预订先在该账号下创建一笔预订再调用 List Bookings 模块Localhost 无法作为 Base URLMake 无法访问内网地址使用 ngrok 等隧道工具将本地实例暴露为公网 HTTPS 地址七、总结Cal.diy 的 Make 集成是一套安装即用的自动化入口用户侧只需完成生成 API Key → 在 Make 中创建连接与场景两步即可把预订生命周期中的创建、删除、改期、会议结束四类事件实时推送到任意自动化流程中开发者侧则可直接复用 packages/app-store/make/api 下基于scheduleTrigger与findValidApiKey构建的订阅/查询/删除/校验四类端点理解appId与 API Key 绑定这一鉴权模型就能在此基础上扩展出更多面向自动化平台的集成。无论是云端实例还是自建部署这套集成都能让预订即数据、事件即自动化成为现实。【免费下载链接】cal.diyScheduling infrastructure for absolutely everyone.项目地址: https://gitcode.com/GitHub_Trending/ca/cal.diy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考