GHL自定义Webhook处于Waiting状态的解决方案及响应变量使用咨询

一、Webhook卡在「Waiting」状态的解决方法 #

• 校验API响应规范：GHL对Webhook响应有严格要求，必须满足：
  • 响应格式为标准JSON，不能返回HTML、纯文本等非JSON内容；
  • 请求头Content-Type必须设置为application/json；
  • 返回2xx系列状态码（如200、201），4xx/5xx状态码会导致GHL无法正确识别完成状态。
    可以用Postman模拟GHL的请求参数发送到API，确认响应完全符合上述要求。
• 调整超时设置：GHL自定义Webhook默认超时时间较短（通常10秒内），如果API处理耗时超过阈值，就会显示「Waiting」。检查Webhook设置中是否有超时调整选项，适当延长；同时优化API的响应速度（比如减少数据库查询、异步处理非核心逻辑）。
• 排查流程依赖冲突：单独测试Webhook正常，但完整流程中卡住，大概率是流程中其他动作导致的冲突。比如前置动作未完成、并行动作抢占资源，或者后续动作阻塞了Webhook的状态更新。可以逐步简化流程，只保留Webhook动作测试，再逐个添加其他动作定位问题点。

二、工作流执行两次的问题排查 #

• 检查触发规则：确认工作流的触发条件没有重复或重叠，比如同时设置了「联系人添加」和「标签自动添加」两个触发规则，会导致同一操作触发两次工作流。只保留唯一的触发条件测试。
• 排查GHL重试机制：如果GHL首次请求未收到响应（哪怕API已经处理完成），会自动重试导致两次执行。通过GHL工作流日志查看Webhook的请求记录，确认是否存在重复请求，同时确保API的网络稳定性，避免丢包或延迟。
• 测试单个联系人操作：如果是批量添加联系人导致的重复执行，尝试单个添加联系人，看是否还会触发两次。批量操作可能存在系统延迟，导致GHL重复触发工作流。

三、Webhook响应作为自定义变量的替代方案 #

如果自定义Webhook的响应无法直接在分支中使用，可以用以下方式处理：

• 存储到联系人自定义字段：在Webhook动作后添加「更新自定义字段」动作，通过{{webhookResponse.xxx}}（xxx为响应中的字段名）提取响应值，保存到联系人的自定义字段中，后续If/Else分支直接调用该字段即可。
• 使用GHL数据存储：若不需要关联到联系人，可将Webhook响应存储到GHL的数据存储模块，后续流程通过查询数据存储获取对应值。
• 替换为GHL内置API动作：GHL自带的「API动作」对响应处理更原生，能直接将响应值作为流程变量使用，避免自定义Webhook的兼容性问题，优先尝试这种方式。

四、通用排查步骤 #

1. 查看GHL工作流日志：在工作流的执行记录中，查看Webhook的请求详情、响应内容、状态码，这是定位问题最直接的方式；
2. 隔离测试：将Webhook从原流程中剥离，单独创建测试流程，验证是否能正常完成；
3. 模拟请求：用Postman或curl模拟GHL的请求参数，确认API的响应是否符合预期。

内容的提问来源于stack exchange，提问作者Nazar Andrushko