用途：帮助开发者搭建 BigCommerce Webhook 接收端，处理订单、商品、客户、购物车等事件，并解决签名验证失败等问题。
主要能力：BigCommerce 的钩子只能通过 API 创建（无后台界面），使用 POST /stores/{store_hash}/v3/hooks 并携带 X-Auth-Token。事件载荷为「瘦」载荷，data 只含资源类型与 id，需要根据 scope 回调用 REST API 获取完整资源。收到后应立即返回 HTTP 200，慢操作放到异步执行。
签名验证：官方按 Standard Webhooks 规范说明回调签名，建议使用该规范的库。请求头为 webhook-id、webhook-timestamp、webhook-signature（v1,<base64>），签名是对 {webhook-id}.{webhook-timestamp}.{rawBody} 做 HMAC-SHA256 计算，密钥为应用的 client secret。使用 standardwebhooks 库时需先把 client secret 做 base64 编码传入，并且必须传原始请求体，不能先 JSON.parse。Node 与 Python 示例仅展示这一核心步骤。
常见事件：store/order/created、store/order/updated、store/order/statusUpdated、store/product/created、store/product/updated、store/product/deleted、store/product/inventory/updated、store/customer/created、store/cart/created、store/cart/abandoned 等，按 scope 字段分发。
使用方式：环境变量需设置 BIGCOMMERCE_CLIENT_SECRET；若需回调 REST API 补充资源详情，还需 store hash 与 access token。本地开发时 BigCommerce 要求 443 端口的 HTTPS 端点，可用 npx hookdeck-cli listen 3000 bigcommerce --path /webhooks/bigcommerce 建立隧道，再用 curl 创建指向隧道地址的钩子，新钩子最多约一分钟才激活。
限制：官方文档目前未明确列出这些请求头名称、未说明该功能是否 GA，也未澄清签名是否适用于所有钩子还是仅应用创建的钩子，建议在首次投递时记录请求头确认；若钩子没有签名，则改用创建时设置的请求头。投递失败会在大约 48 小时内重试，超时后钩子被停用；某域名两分钟内成功率低于 90% 会被封禁 3 分钟。资料未提供收费与价格信息。