Webhook

订单状态变化时，Delieta 不会调用你的服务器。已发布的 OpenAPI 没有面向合作方的 webhook 操作。只有一个发往运行 @delieta/shop-runtime 的店铺的签名信号，以及一个反方向的报告。

刷新信号：POST /api/revalidate

店主修改菜单、店铺设置或平面图时，Delieta 会调用 POST {店铺部署地址}/api/revalidate。店铺使缓存失效，下一次请求就取到新数据。请求体为 {"reason":"menu"|"shop-config"|"floor-plan","at":"…ISO…"}。

POST /api/revalidate
x-delieta-signature: 9f2c…
Content-Type: application/json

{"reason":"menu","at":"2026-11-05T12:00:00.000Z"}

签名是 x-delieta-signature 请求头：对原始请求体做十六进制 HMAC-SHA256，密钥是该店铺的刷新密钥（店铺侧为 DELIETA_REVALIDATE_SECRET）。@delieta/shop-runtime 的处理器以恒定时间校验签名。签名错误 → 401，店铺没有密钥 → 503，请求体有误 → 400，成功 → 204。Delieta 最多等待 5 秒并忽略失败：刷新是便利，不是事务。店铺本来就不缓存地读取 Delieta，所以最坏的结果只是延迟。

这个地址靠签名而不是 API 密钥提供服务。里面没有可发布密钥，也没有合作方密钥。

店铺心跳

反方向上，已部署的店铺报告它是用哪个 runtime 构建的：POST /api/v1/shop-heartbeat。每次构建一次，由 delieta-shop-assert 在 next build 之后发送。Delieta 把 runtime 和契约版本存到店铺记录上，从而知道哪些店铺需要更新。始终 204；无需处理任何东西。

订单状态：用 GET 读取

POST /api/v1/orders 之后，订单可能处于 pending_acceptance。当厨房里的人接单或拒单，或超时到达时，它才会离开该状态。这些都不是你的后端引起的，所以你要去读：用保密密钥调用 GET /api/v1/orders/{id}，或按短码调用 GET /api/v1/orders/{id}/status（可发布密钥也行）。查询计入读取限额，不占用创建订单的限额。

404 not_found 表示“此密钥下没有这笔订单”。其他公司的订单回答相同。

没有什么

没有发往 https://your-shop/hooks/orders 的状态变更签名 POST。没有合作方 webhook 密钥，我们这边也没有重试。你的公司向 Delieta 付款走 Stripe，是面板的事，不属于 Partner API。合作方 webhook 上线后，会作为新操作出现在 GET /api/v1/openapi 和 Partner API 页面中。