接收事件
Webhook 投遞同簽章驗證
UnifyPort 點樣經 HTTP POST 將事件投遞去你嘅接收位址、每次投遞帶嘅 X-Device-* 請求標頭,以及點樣驗證 HMAC-SHA256 簽章去確認載荷可信。仲會講埋我哋預期嘅回應、重試同冪等。
投遞請求標頭
X-Device-Event-Id事件嘅穩定 id。同一事件嘅多次重試保持不變——同投遞 id 一齊用嚟做冪等去重。
X-Device-Delivery-Id今次單獨投遞嘗試嘅 id。冇單獨設定時回退做事件 id。
X-Device-Timestamp今次投遞簽章時嘅 RFC 3339 UTC 時間(例如 2026-06-08T12:34:56Z)。佢係簽章字串嘅一部分,亦可以用嚟拒絕過期投遞。
X-Device-Signature對 "<X-Device-Timestamp>" + "." + "<原始請求內文>" 計出嘅十六進位 HMAC-SHA256。淨係當端點設定咗 signing_secret 先會有;關閉簽章時唔會傳送。
Content-Type一律係 application/json。
驗證簽章
Node.js (Express)
import crypto from 'crypto';
import express from 'express';
const app = express();
const SECRET = process.env.WEBHOOK_SIGNING_SECRET;
// express.raw keeps the body as the exact bytes we signed — never re-serialize.
app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => {
let timestamp = req.get('X-Device-Timestamp');
if (!timestamp) {
timestamp = '';
}
let signature = req.get('X-Device-Signature');
if (!signature) {
signature = '';
}
const hmac = crypto.createHmac('sha256', SECRET);
hmac.update(timestamp + '.');
hmac.update(req.body); // raw Buffer
const expected = hmac.digest('hex');
const valid =
signature.length === expected.length &&
crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
if (!valid) return res.status(401).end();
const event = JSON.parse(req.body.toString('utf8'));
// handle event.type ...
res.status(200).end(); // any 2xx acknowledges the delivery
});Python (Flask)
import hmac, hashlib, os
from flask import Flask, request, abort
app = Flask(__name__)
SECRET = os.environ["WEBHOOK_SIGNING_SECRET"].encode()
@app.post("/webhook")
def webhook():
timestamp = request.headers.get("X-Device-Timestamp", "")
signature = request.headers.get("X-Device-Signature", "")
body = request.get_data() # raw bytes, exactly as delivered
expected = hmac.new(
SECRET, timestamp.encode() + b"." + body, hashlib.sha256
).hexdigest()
if not hmac.compare_digest(signature, expected):
abort(401)
event = request.get_json()
# handle event["type"] ...
return "", 200備註
- 用任何 2xx 狀態確認。回應內文會被讀取再丟棄;非 2xx 當做投遞失敗。
- 連線錯誤同 408 / 429 / 5xx 回應會按 retry_policy.max_attempts 重試(預設 3 次)。其他 4xx 唔重試,事件入死信。
- 投遞語意係至少一次(at-least-once)。重試會重用同一個 X-Device-Event-Id,請按佢去重,唔好假設恰好一次。
- 請對原始請求位元組做驗證,而且要喺任何 JSON 解析 / 重新序列化之前。重新編碼內文會改變位元組、令簽章對唔上。
- 拒絕 X-Device-Timestamp 同本地時鐘相差太遠嘅投遞嚟限制重放——時間戳已經被簽章覆蓋。
- 簽章係按端點設定:喺建立或者更新 webhook 端點時設定 signing_secret 就開啟;留空就關閉,亦唔再傳送 X-Device-Signature 標頭。
- 投遞唔保證順序——同一會話嘅事件可能亂序到達(已讀回執可能早過佢指向嘅訊息到)。請按 occurred_at 排序(事件 id 做並列時嘅次序鍵)先至套用狀態。
- UnifyPort 唔會持久化訊息歷史,亦冇訊息查詢 API——webhook 事件係流量嘅唯一紀錄。事件到嗰陣就要將需要嘅內容存低;漏咗嘅載荷之後冇辦法補返。