仅订阅最少数量的事件
您只应订阅所需的 webhook 事件。这将减少服务器需要处理的工作量。有关订阅事件的更多信息，请参阅 创建 webhook 和 编辑 webhook。
使用 webhook 密钥
警告
为避免敏感信息意外泄露，请不要在有效负载 URL 中包含敏感信息。这包括您自己的 API 密钥和其他身份验证凭证。相反，为了验证 webhook 投递是由 GitHub 发送且未被篡改，请使用 webhook 密钥。更多信息请参阅 验证 webhook 投递。
webhook 密钥应为高熵的随机文本字符串。您应以安全的方式存储 webhook 密钥，以便服务器能够访问。
使用 HTTPS 并进行 SSL 验证
您应确保服务器使用 HTTPS 连接。默认情况下，GitHub 在投递 webhook 时会验证 SSL 证书。GitHub 建议保持 SSL 验证开启。
允许 GitHub 的 IP 地址
您可以为服务器设置 IP 白名单，并添加 GitHub 用于 webhook 投递的 IP 地址。这可以阻止伪造请求。
您可以使用 GET /meta 接口获取当前的 GitHub IP 地址列表。更多信息请参阅 获取 GitHub 元信息的 REST API 端点。GitHub 会不定期更改其 IP 地址，因此应定期更新 IP 白名单。
更多信息，请参阅 关于 GitHub 的 IP 地址。
在 10 秒内作出响应
服务器应在收到 webhook 投递后的 10 秒内返回 2XX 响应。如果服务器响应时间超过此限制，GitHub 将终止连接并视为投递失败。
为及时响应，您可能需要建立队列以异步处理 webhook 有效负载。服务器在收到 webhook 时即可响应，然后在后台处理负载，而不会阻塞后续的 webhook 投递。例如，您可以使用 Hookdeck 等服务，或使用 Resque（Ruby）、RQ（Python）或 RabbitMQ（Java）等库。
在处理事件前检查事件类型和动作
Webhook 有多种事件类型，且许多事件可能包含多种动作。GitHub 不断为现有事件类型添加新的事件类型和动作。您的应用应在处理 payload 前检查 webhook 的事件类型和动作。要获取事件类型，可使用 X-GitHub-Event 请求头。要获取动作类型，可在事件 payload 的顶层使用 action 键。
重新投递遗漏的交付
如果服务器宕机，服务器恢复后应重新投递遗漏的 webhook。更多信息请参阅 重新投递 webhook。
使用 X-GitHub-Delivery 头部
在重放攻击中，恶意行为者拦截 webhook 投递并重新发送。为防范重放攻击，您可以使用 X-GitHub-Delivery 头部，以确保每个投递在同一事件中唯一。
注意
如果您请求重新投递，X-GitHub-Delivery 头部将与原始投递相同。