租用號碼上的進線事件與收件匣：沒有 webhook 混亂的雙向維運

外呼有路線圖投影片；入站有呼叫器。客戶在租用號碼上回覆 STOP、傳來照片或回撥時，事件必須落進你的系統——支援信得過的收件匣，不是散落日誌。沒有入站紀律的雙向，只是單向承諾外加投訴佇列。

IOSOR 分配租用號碼，配套入站 webhook 與對客戶安全的錯誤——白標介面，日常維運不必另開門戶。月平台用量接近 USD 1,000+ 時，webhook 鑑權證據、STOP 日誌與收件匣關聯會進入更緊密的商務複盤。先拿證據，再談擴量。對外承諾須與目錄 live / in setup 一致。

必須規劃的事件類型

漏掉 STOP 是合規事故，不是「稍後補日誌」。漏掉 DLR 與外呼關聯，財務月末只能盲對帳。對照 雙向訊息收件匣指南 與 STOP 與 HELP 關鍵詞政策。目錄標 live 的雙向必須覆蓋上表四類；in setup 不是生產雙向。

入站 Webhook 紀律

• 認證每一筆入站請求
• 處理器必須冪等——重試是常態
• 先持久化，再做副作用（工單、自動回覆、CRM）
• 死信佇列加可回放工具

對照 入站 webhook 的重試與冪等。目錄已經 live 卻不鑑權 webhook，無法辯護。平台會重試；消費者若把重試當成新事件，收件匣與帳本一起炸。快速 ACK，非同步處理；先落庫再自動回覆。

沒有詐騙漏洞的收件匣體驗

收件匣不是聊天玩具——它是證據：

1. 展示號碼、時間戳、脫敏正文。
2. 回覆成執行緒時，關聯外呼上下文。
3. 限流自動回覆，防止迴路。
4. 合規詢問時可稽核匯出。

座席絕不看到原始上游載荷。原始診斷進維運通道，不進客服螢幕。無限流的自動回覆會在誤設定時把預付費打空。

租用號碼生命週期與收件匣

號碼按 UTC 日曆月續費；釋放必須乾淨切斷入站。寫清誰續租、誰退役——財務不該從憤怒客戶那裡才知道號碼已死。配對 本地與免付費號碼的租用現實。目錄仍為 in setup 就不是雙向生產。沒有活分配的收件匣列是幽靈工單。預付費仍走同一本白標錢包。

危險訊號

• 生產號碼上入站仍寫「即將推出」
• 沒有去重，工單重複
• 無同意上下文就自動回覆
• 無法追溯哪個號碼收到事件
• 座席看到原始上游載荷
• 目錄 live 但 webhook 未簽名
• 號碼已釋放，入站仍在投遞
• 對外承諾雙向，目錄卻是 in setup

開始使用 IOSOR

指派一個租用的雙向號碼。發一則測試 MO。打開收件匣，確認一列裡有 DID、租戶和 correlation id。從死信重放同一事件，確認沒有第二列。把客服會大聲念出的 STOP 路徑交給他們。這是租用 DID 上的收件匣物件，不是閘道鎖，也不是洪峰限速。

IOSOR 要點

租用號碼收件匣是客服列。Webhook 2xx 沒有列就是靜默丟件。

該做：把每則 MO 綁到坐席能打開的一列。別做：把入站丟在原始日誌裡還叫它收件匣。