進站簡訊 Webhook：重試、事件順序與接收冪等

出站簡訊占據儀表板。進站才是 STOP、HELP 與客戶回覆真正落地之處——也是天真處理器製造重複工單、雙重錢包副作用，以及「我們從未收到 STOP」合規幽靈的地方。若接收路徑假設嚴格有序的恰好一次投遞，第一次真實故障就會擊垮你。

IOSOR 將進站訊息放在與出站相同的白標預付費表面上：可核驗的事件、品牌安全酬載，無需窩在外來營運入口核對回覆風暴。

為何 Webhook 會重試

. Your server might return 200 . at-least-once delivery with retries on timeout, 5xx, and ambiguous network errors.

必須設計的三種失敗模式

冪等：同時修好三種失敗的一個屬性

進站並非沒有金錢與營運副作用：

• 自動回覆可能借記預付費錢包
• STOP 處理必須抑制未來行銷發送
• 開單的客服巨集不可因三次 POST 開三張單

冪等接收處理器清單：

1. 副作用前先持久化進站事件 id
2. 用先前結果短路重複
3. 自動回覆發送自帶冪等鍵
4. 記錄進站 id → 錢包行 → 回覆 id 的關聯
5. 失敗文案對操作員保持白標安全

接近每月 USD 1,000+ 平台用量時，進站重複風暴會變成財務與合規對話——試點仍可先在低量關鍵字上證明台帳。

事件順序：為何「最後寫入獲勝」危險

常見錯誤假設：

1. STOP 一定先於下一次行銷發送到達（存在競態）
2. 出站送達回執一定先於進站回覆（路徑獨立）
3. 無耐久事件鍵卻聲稱「首次 POST 勝出」

用耐久的 事件／訊息 id 建立接收台帳。業務規則應是台帳上的狀態轉移，而非「每個 HTTP 200 路徑都跑副作用」。

. . . .

2xx — typically under a second. . .

1. 進站回呼的書面重試策略
2. 可測試的簽章／鑑權核驗
3. 酬載中的耐久事件 id
4. 冪等處理器指引（不只是「回傳 200」）
5. 在重複投遞下仍存活的 STOP／HELP 路徑
6. 任何自動回覆支出可見於同一預付費錢包

危險信號

• 「我們從不重試」（你會丟掉合規事件）
• 沒有事件 id——只有時間戳記
• 文件假定嚴格全域順序
• 自動回覆風暴卻無線索進錢包
• 營運要求第三方入口才能重放進站

從 IOSOR 開始

拉上週入站 webhook 日誌，數有多少事件 ID 到過兩次以上。回放一則重複與一對亂序（先 failed 後 delivered）。接收端只能留一個效果：一列收件、一次 STOP 寫入、一次錢包觸碰。後寫覆蓋把 STOP 撤掉算失敗。這是接收冪等與重試順序，不是簽章驗證，也不是入列前的閘道鎖。

相關閱讀: 入站自動回覆循環抽錢包 · 緩衝進站 Webhook 處理以應對電信商延遲飆升 · 首次扣款前的預付資金保留.

IOSOR 要點

入站 webhook 會重試。接收冪等是唯一安全答案；順序不是承諾。

該做：給事件加鍵，丢掉孿生件。別做：對 STOP 用後寫覆蓋，或同一事件扣兩次。