Zoom Healthcare REST API 端点指南Clinical Notes 操作清单与集成实践【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins本篇指南以 Zoom Healthcare API 的权威端点清单为骨架系统梳理其全部 3 个 Clinical Notes临床笔记相关操作涵盖端点路径、HTTP 方法、操作 ID、认证前提与调用约定并结合本仓库rest-apiskill 中的认证参考与架构文档给出从获取 Access Token 到实际发起请求的完整集成路径。读者读完本篇后将能在 knowledge-work-plugins 项目的 Zoom REST API 技能体系内快速完成 Healthcare 临床笔记的端点发现、权限核对与编码实现。文档定位与项目上下文healthcare.md是 Zoom REST API skill 中面向 Healthcare 产品线的端点清单endpoint inventory参考文件与同目录下的 meetings.md、users.md、contact-center.md 等 39 个领域参考文件采用同一套生成式结构它们均镜像官方 Zoom API Hub 的 OpenAPI 文档paths对象作为项目内的“本地事实来源local source of truth”用于端点发现与盘点endpoint discovery and inventory。在该 skill 的完整体系SKILL.md中本文件属于 References 层级而具体的业务流程编排如会议生命周期、用户管理、Webhook 服务器应参考 examples/ 目录下的完整示例。也就是说本文件回答“有哪些端点、叫什么、怎么调用”examples 回答“如何组合这些端点完成一个业务流程”。Canonical Source权威来源与基础 URL文件开篇明确了该清单的权威来源所有端点路径、方法与操作 ID 均由此生成OpenAPI JSON 来源官方 Zoom API Hub 中 Healthcare 域的endpoints.json方法清单developers.zoom.us/api-hub/healthcare/methods/endpoints.json。该 JSON 直接驱动了本文档中paths对象的表格化呈现保证清单与线上文档同步、可追踪Base URLhttps://api.zoom.us/v2。这是 Zoom REST API 的全局基础地址所有 Healthcare 端点都拼接在此地址之后认证细节完整认证方案见 authentication.md。关于 Base URL 需要补充两点依据 api-architecture.md区域化 Base URLOAuth 令牌响应中的api_url字段标识用户所属数据区域如https://api-eu.zoom.us出于数据驻留data residency合规要求可将/v2拼接到区域域名后使用但全局地址https://api.zoom.us始终可用与区域无关版本前缀REST 使用/v2GraphQL 则使用独立的/v3/graphql端点二者不要混用。认证前提Server-to-Server OAuth 是后端集成的默认路径调用 Healthcare 端点前必须先取得 Bearer Access Token。根据 authentication.mdZoom API 支持三种认证方式各有适用场景认证方式适用场景令牌生命周期User OAuth 2.0以具体用户身份执行操作Access Token 1 小时Refresh Token 约 15 年Server-to-Server OAuth后端自动化、无需用户交互Access Token 1 小时JWT已弃用遗留集成自定义对于 Clinic Notes 这类由医疗后台系统触发的数据读写Server-to-Server OAuth 是推荐路径。其核心流程为在 Zoom App Marketplace 创建Server-to-Server OAuth应用记录 Account ID、Client ID、Client Secret 三项凭证用凭证换取访问令牌curl -X POST https://zoom.us/oauth/token \ -H Authorization: Basic $(echo -n {clientId}:{clientSecret} | base64) \ -H Content-Type: application/x-www-form-urlencoded \ -d grant_typeaccount_credentialsaccount_id{accountId}响应中携带access_token、token_type: bearer、expires_in: 3600与授权 scope 列表{ access_token: eyJhbGciOiJIUzI1NiJ9..., token_type: bearer, expires_in: 3600, scope: meeting:read meeting:write user:read }注意本文档healthcare.md明确提醒每个操作的 scope 名称单独定义且常常使用细粒度granularscope 名称。因此令牌中应包含与 Clinical Notes 读写对应的精确 scope落地前务必到 API Hub 对应操作页面核对所需 scope避免出现401/“does not contain scopes”类错误。此外依据 SKILL.md 中记录的通用规则使用 Server-to-Server OAuth 时不要在路径中使用me关键字S2S 应用必须提供实际的 userId 或 email该限制对 Healthcare 端点同样适用集成时需留意宿主/用户身份的传参方式。使用注意事项Notes清单文件给出了三条使用约定直接决定开发者应如何消费本文件端点方法与路径由官方 Zoom API Hub 的paths对象生成——本文档不是手工维护的“推荐路径”而是镜像官方 OpenAPI 的机械生成物因此路径名以官方为准scope 按操作粒度定义——每个操作都有各自的 scope经常是细粒度名称实现前必须打开 API Hub 的对应操作页核对精确 scope不能想当然复用同一 scope本文件只用于端点发现与盘点——路径名的权威来源是本文件但业务编排模式应参考../examples/仓库中对应 examples/ 目录不要把 examples 当作路径名的规范来源也不要把本文件当作编排示例。简言之查路径查这里学编排去 examples二者职责分离、互为补充。覆盖范围概览CoverageHealthcare 域当前在清单中登记的接口规模如下指标值端点操作Endpoint operations3路径模板Path templates2标签Tags1对比同目录下其他领域例如 contact-center.md 登记 278 个操作、157 个路径模板、25 个标签Healthcare 是一个小而专的接口面全部功能收敛在一个 tag、两条路径模板之下实现成本低、边界清晰非常适合作为后端子系统的首批集成目标。Tag 索引clinicalnotesTagOperationsclinicalnotes3全部 3 个操作都归属clinicalnotes临床笔记标签即当前 Healthcare 清单的唯一功能模块。从命名可以推断该模块负责临床笔记Clinical Notes这一医疗场景核心文档的读取与维护尚未包含诸如就诊、处方、预约等其他医疗业务域。端点详解clinicalnotes以下按标签逐一列出全部 3 个操作方法、端点、摘要、操作 ID 均取自 healthcare.md 原表MethodEndpointSummaryOperation IDGET/clinical_notes/notesList clinical notesGetClinicalNoteGET/clinical_notes/notes/{noteId}Get a Clinical NoteGetaClinicalNotePATCH/clinical_notes/notes/{noteId}Update a Clinical NoteUpdateClinicalNote列出临床笔记GET /clinical_notes/notes用途拉取临床笔记列表路径https://api.zoom.us/v2/clinical_notes/notes操作 IDGetClinicalNote注意该 ID 未区分复数/单数与下方单条查询的GetaClinicalNote高度相似编码与检索时需仔细辨别。列表类操作通常伴随分页参数。虽然本文档未逐字段列出请求参数但依据 Zoom REST API 通用分页约定见 SKILL.md 与 api-architecture.md列表接口普遍支持page_size与游标式分页next_page_tokenpage_number为遗留参数、正被逐步淘汰可以推断该端点同样适用于“先翻页拉全量、再按 noteId 逐条深入”的典型集成模式。响应中的next_page_token应原样传给下一轮请求以继续翻页直至返回空令牌。获取单个临床笔记GET /clinical_notes/notes/{noteId}用途按笔记 ID 获取单条临床笔记详情路径模板https://api.zoom.us/v2/clinical_notes/notes/{noteId}其中{noteId}为笔记唯一标识操作 IDGetaClinicalNote。该端点通常与列表端点配套使用先通过列表接口获得noteId集合再逐条获取完整内容。调用时需将{noteId}替换为实际 ID若 ID 包含需要编码的特殊字符Zoom 体系内部分 UUID 需双重 URL 编码参见 api-architecture.md 中的双编码规则务必按相同规则处理后再拼接路径。更新临床笔记PATCH /clinical_notes/notes/{noteId}用途部分更新一条已有临床笔记路径模板https://api.zoom.us/v2/clinical_notes/notes/{noteId}操作 IDUpdateClinicalNoteHTTP 方法PATCH——表示部分字段更新语义请求体只需携带要修改的字段而非整条资源替换若按 REST 惯例推断全量替换应由 PUT 承担本清单未登记 PUT说明当前更新入口统一收敛在 PATCH 上。该操作是临床笔记工作流中的“写”入口常用于诊断结论修订、医嘱补充、审核批注等场景。医疗数据对变更合规要求高建议在业务层面对更新前/后的内容留痕并在调用前确认令牌 scope 已包含该写操作所需的细粒度权限。实战从认证到调用的完整流程将上述信息串起来一条最小可用的 Healthcare 调用链路如下以列表接口为例取令牌Server-to-Server OAuth见上文认证小节发起请求curl -X GET https://api.zoom.us/v2/clinical_notes/notes?page_size50 \ -H Authorization: Bearer {access_token} \ -H Content-Type: application/json处理响应解析next_page_token判断是否还有下一页对PATCH更新操作请求体传入待更新字段的 JSON 对象错误处理401通常意味着令牌过期或缺少对应 scope参考 authentication.md 的 OAuth 错误表如invalid_grant、invalid_client429表示触发限流应关注响应头中的剩余额度并实现退避重试SKILL.md 强调限流按账户而非按应用计算。编排与更多资源本文件是端点清单而非编排示例组合使用 Clinical Notes 与其他 Zoom 资源如把笔记与会话、用户关联时请参考仓库内以下资源编排模式examples/ 目录下的 meeting-lifecycle.md、user-management.md 等示例展示了端点组合、分页与错误处理范式可套用于 Healthcare 场景认证实现references/authentication.md 提供完整的 Node.js/Express 认证代码S2S 与 User OAuth 双路径与令牌存储最佳实践架构约定concepts/api-architecture.md 覆盖 Base URL、me关键字、ID/UUID 双编码与时间格式等所有调用层细节排障入口遇到问题可先走 RUNBOOK.md 预检流程再对照 troubleshooting/ 目录中的错误码与常见问题处理。小结Zoom Healthcare API 当前通过clinicalnotes标签下的 2 条路径、3 个操作提供了临床笔记的“列表—详情—更新”完整读写闭环。集成时牢记三点以本文档为路径权威来源、以 API Hub 操作页核对细粒度 scope、以 examples 目录学习编排模式即可将该能力平滑接入医疗后台系统。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Zoom Healthcare REST API 端点指南：Clinical Notes 操作清单与集成实践
Zoom Healthcare REST API 端点指南Clinical Notes 操作清单与集成实践【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins本篇指南以 Zoom Healthcare API 的权威端点清单为骨架系统梳理其全部 3 个 Clinical Notes临床笔记相关操作涵盖端点路径、HTTP 方法、操作 ID、认证前提与调用约定并结合本仓库rest-apiskill 中的认证参考与架构文档给出从获取 Access Token 到实际发起请求的完整集成路径。读者读完本篇后将能在 knowledge-work-plugins 项目的 Zoom REST API 技能体系内快速完成 Healthcare 临床笔记的端点发现、权限核对与编码实现。文档定位与项目上下文healthcare.md是 Zoom REST API skill 中面向 Healthcare 产品线的端点清单endpoint inventory参考文件与同目录下的 meetings.md、users.md、contact-center.md 等 39 个领域参考文件采用同一套生成式结构它们均镜像官方 Zoom API Hub 的 OpenAPI 文档paths对象作为项目内的“本地事实来源local source of truth”用于端点发现与盘点endpoint discovery and inventory。在该 skill 的完整体系SKILL.md中本文件属于 References 层级而具体的业务流程编排如会议生命周期、用户管理、Webhook 服务器应参考 examples/ 目录下的完整示例。也就是说本文件回答“有哪些端点、叫什么、怎么调用”examples 回答“如何组合这些端点完成一个业务流程”。Canonical Source权威来源与基础 URL文件开篇明确了该清单的权威来源所有端点路径、方法与操作 ID 均由此生成OpenAPI JSON 来源官方 Zoom API Hub 中 Healthcare 域的endpoints.json方法清单developers.zoom.us/api-hub/healthcare/methods/endpoints.json。该 JSON 直接驱动了本文档中paths对象的表格化呈现保证清单与线上文档同步、可追踪Base URLhttps://api.zoom.us/v2。这是 Zoom REST API 的全局基础地址所有 Healthcare 端点都拼接在此地址之后认证细节完整认证方案见 authentication.md。关于 Base URL 需要补充两点依据 api-architecture.md区域化 Base URLOAuth 令牌响应中的api_url字段标识用户所属数据区域如https://api-eu.zoom.us出于数据驻留data residency合规要求可将/v2拼接到区域域名后使用但全局地址https://api.zoom.us始终可用与区域无关版本前缀REST 使用/v2GraphQL 则使用独立的/v3/graphql端点二者不要混用。认证前提Server-to-Server OAuth 是后端集成的默认路径调用 Healthcare 端点前必须先取得 Bearer Access Token。根据 authentication.mdZoom API 支持三种认证方式各有适用场景认证方式适用场景令牌生命周期User OAuth 2.0以具体用户身份执行操作Access Token 1 小时Refresh Token 约 15 年Server-to-Server OAuth后端自动化、无需用户交互Access Token 1 小时JWT已弃用遗留集成自定义对于 Clinic Notes 这类由医疗后台系统触发的数据读写Server-to-Server OAuth 是推荐路径。其核心流程为在 Zoom App Marketplace 创建Server-to-Server OAuth应用记录 Account ID、Client ID、Client Secret 三项凭证用凭证换取访问令牌curl -X POST https://zoom.us/oauth/token \ -H Authorization: Basic $(echo -n {clientId}:{clientSecret} | base64) \ -H Content-Type: application/x-www-form-urlencoded \ -d grant_typeaccount_credentialsaccount_id{accountId}响应中携带access_token、token_type: bearer、expires_in: 3600与授权 scope 列表{ access_token: eyJhbGciOiJIUzI1NiJ9..., token_type: bearer, expires_in: 3600, scope: meeting:read meeting:write user:read }注意本文档healthcare.md明确提醒每个操作的 scope 名称单独定义且常常使用细粒度granularscope 名称。因此令牌中应包含与 Clinical Notes 读写对应的精确 scope落地前务必到 API Hub 对应操作页面核对所需 scope避免出现401/“does not contain scopes”类错误。此外依据 SKILL.md 中记录的通用规则使用 Server-to-Server OAuth 时不要在路径中使用me关键字S2S 应用必须提供实际的 userId 或 email该限制对 Healthcare 端点同样适用集成时需留意宿主/用户身份的传参方式。使用注意事项Notes清单文件给出了三条使用约定直接决定开发者应如何消费本文件端点方法与路径由官方 Zoom API Hub 的paths对象生成——本文档不是手工维护的“推荐路径”而是镜像官方 OpenAPI 的机械生成物因此路径名以官方为准scope 按操作粒度定义——每个操作都有各自的 scope经常是细粒度名称实现前必须打开 API Hub 的对应操作页核对精确 scope不能想当然复用同一 scope本文件只用于端点发现与盘点——路径名的权威来源是本文件但业务编排模式应参考../examples/仓库中对应 examples/ 目录不要把 examples 当作路径名的规范来源也不要把本文件当作编排示例。简言之查路径查这里学编排去 examples二者职责分离、互为补充。覆盖范围概览CoverageHealthcare 域当前在清单中登记的接口规模如下指标值端点操作Endpoint operations3路径模板Path templates2标签Tags1对比同目录下其他领域例如 contact-center.md 登记 278 个操作、157 个路径模板、25 个标签Healthcare 是一个小而专的接口面全部功能收敛在一个 tag、两条路径模板之下实现成本低、边界清晰非常适合作为后端子系统的首批集成目标。Tag 索引clinicalnotesTagOperationsclinicalnotes3全部 3 个操作都归属clinicalnotes临床笔记标签即当前 Healthcare 清单的唯一功能模块。从命名可以推断该模块负责临床笔记Clinical Notes这一医疗场景核心文档的读取与维护尚未包含诸如就诊、处方、预约等其他医疗业务域。端点详解clinicalnotes以下按标签逐一列出全部 3 个操作方法、端点、摘要、操作 ID 均取自 healthcare.md 原表MethodEndpointSummaryOperation IDGET/clinical_notes/notesList clinical notesGetClinicalNoteGET/clinical_notes/notes/{noteId}Get a Clinical NoteGetaClinicalNotePATCH/clinical_notes/notes/{noteId}Update a Clinical NoteUpdateClinicalNote列出临床笔记GET /clinical_notes/notes用途拉取临床笔记列表路径https://api.zoom.us/v2/clinical_notes/notes操作 IDGetClinicalNote注意该 ID 未区分复数/单数与下方单条查询的GetaClinicalNote高度相似编码与检索时需仔细辨别。列表类操作通常伴随分页参数。虽然本文档未逐字段列出请求参数但依据 Zoom REST API 通用分页约定见 SKILL.md 与 api-architecture.md列表接口普遍支持page_size与游标式分页next_page_tokenpage_number为遗留参数、正被逐步淘汰可以推断该端点同样适用于“先翻页拉全量、再按 noteId 逐条深入”的典型集成模式。响应中的next_page_token应原样传给下一轮请求以继续翻页直至返回空令牌。获取单个临床笔记GET /clinical_notes/notes/{noteId}用途按笔记 ID 获取单条临床笔记详情路径模板https://api.zoom.us/v2/clinical_notes/notes/{noteId}其中{noteId}为笔记唯一标识操作 IDGetaClinicalNote。该端点通常与列表端点配套使用先通过列表接口获得noteId集合再逐条获取完整内容。调用时需将{noteId}替换为实际 ID若 ID 包含需要编码的特殊字符Zoom 体系内部分 UUID 需双重 URL 编码参见 api-architecture.md 中的双编码规则务必按相同规则处理后再拼接路径。更新临床笔记PATCH /clinical_notes/notes/{noteId}用途部分更新一条已有临床笔记路径模板https://api.zoom.us/v2/clinical_notes/notes/{noteId}操作 IDUpdateClinicalNoteHTTP 方法PATCH——表示部分字段更新语义请求体只需携带要修改的字段而非整条资源替换若按 REST 惯例推断全量替换应由 PUT 承担本清单未登记 PUT说明当前更新入口统一收敛在 PATCH 上。该操作是临床笔记工作流中的“写”入口常用于诊断结论修订、医嘱补充、审核批注等场景。医疗数据对变更合规要求高建议在业务层面对更新前/后的内容留痕并在调用前确认令牌 scope 已包含该写操作所需的细粒度权限。实战从认证到调用的完整流程将上述信息串起来一条最小可用的 Healthcare 调用链路如下以列表接口为例取令牌Server-to-Server OAuth见上文认证小节发起请求curl -X GET https://api.zoom.us/v2/clinical_notes/notes?page_size50 \ -H Authorization: Bearer {access_token} \ -H Content-Type: application/json处理响应解析next_page_token判断是否还有下一页对PATCH更新操作请求体传入待更新字段的 JSON 对象错误处理401通常意味着令牌过期或缺少对应 scope参考 authentication.md 的 OAuth 错误表如invalid_grant、invalid_client429表示触发限流应关注响应头中的剩余额度并实现退避重试SKILL.md 强调限流按账户而非按应用计算。编排与更多资源本文件是端点清单而非编排示例组合使用 Clinical Notes 与其他 Zoom 资源如把笔记与会话、用户关联时请参考仓库内以下资源编排模式examples/ 目录下的 meeting-lifecycle.md、user-management.md 等示例展示了端点组合、分页与错误处理范式可套用于 Healthcare 场景认证实现references/authentication.md 提供完整的 Node.js/Express 认证代码S2S 与 User OAuth 双路径与令牌存储最佳实践架构约定concepts/api-architecture.md 覆盖 Base URL、me关键字、ID/UUID 双编码与时间格式等所有调用层细节排障入口遇到问题可先走 RUNBOOK.md 预检流程再对照 troubleshooting/ 目录中的错误码与常见问题处理。小结Zoom Healthcare API 当前通过clinicalnotes标签下的 2 条路径、3 个操作提供了临床笔记的“列表—详情—更新”完整读写闭环。集成时牢记三点以本文档为路径权威来源、以 API Hub 操作页核对细粒度 scope、以 examples 目录学习编排模式即可将该能力平滑接入医疗后台系统。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
