Zendesk集成UI同步问题：如何接收工单更新通知？

针对Zendesk座席操作工单后同步至自定义UI的需求，以下是几种高效替代短轮询的方案：

1. Zendesk Webhooks（推荐实时同步方案） #

• 配置流程：在Zendesk后台创建Webhook，指向你的UI系统的专用接收接口
• 事件触发：选择需要同步的工单事件，比如工单状态变更（关闭/重新打开）、新回复添加、工单字段更新等
• 处理逻辑：当座席在Zendesk端触发对应事件时，Zendesk会自动向你的接口发送POST请求，请求体包含工单的最新完整数据。你可以直接用这些数据更新本地UI或数据库，实现实时同步
• 关键注意点：
  • 启用Webhook签名验证，确保请求来自Zendesk官方，避免伪造请求
  • 处理事件幂等性，比如用Zendesk返回的事件ID作为唯一标识，防止重复更新

2. Zendesk 事件订阅（灵活的动态订阅方案） #

• 基于Zendesk Events API实现，可以通过API动态管理订阅的事件类型
• 接收方式同样支持Webhook端点，适合需要根据业务场景调整订阅规则的场景
• 相比Webhooks，更适合需要批量管理多个订阅或集成复杂业务逻辑的系统

3. 增量API查询（优化版轮询方案） #

如果暂时无法配置Webhooks，可以用Zendesk增量导出API替代全量轮询：

• 实现逻辑：每次查询时带上上次同步的cursor或start_time参数，仅获取自上次同步以来有变更的工单数据
• 优势：仅请求变更数据，请求量和数据量大幅减少，避免全量轮询的低效和限流风险
• 适配建议：结合本地存储的工单updated_at时间戳，进一步校验数据是否需要更新

实践建议 #

• 优先选择Webhooks方案，实时性最高，完全规避轮询带来的性能和限流问题
• 不管采用哪种方案，都要在本地存储工单的核心标识（如Zendesk工单ID）和updated_at时间戳，用于快速校验变更
• 若使用API查询，严格遵循Zendesk的速率限制，必要时实现指数退避的重试策略

内容的提问来源于stack exchange，提问作者Sandeep Bhutani