API 試行週：正式流量的金鑰與 Webhook 設定

API 試行週：正式流量的金鑰與 Webhook 設定。

將 API 金鑰提升至正式流量

從測試環境轉換至正式流量需要妥善隔離營運憑證。在 API 試行週期間，請以受限的正式金鑰取代臨時測試憑證。正式金鑰應具備明確的權限範圍，僅允許發送簡訊或接收 Webhook，而無須全域管理權限。請確保正式 API 憑證存放於安全的密鑰庫中。建議定期輪換金鑰並對敏感操作啟用警報通知，以確保整體金鑰生命週期具備完整的稽核軌跡與權限控管。

在真實資料流上驗證已簽署的 Webhook

接收即時狀態回報(DLR)與進站訊息需要進行密碼學驗證。傳送至您回呼網址的所有酬載皆包含透過您的密鑰計算出的雜湊簽章。在接受任何傳遞更新之前，請先驗證 HTTP 標頭簽章以阻擋偽造事件。務必依據 冪等、重試與資金安全 檢查時間戳記容忍度。透過驗證請求時間戳記，系統能有效阻止重放攻擊，確保傳入您系統的每筆狀態更新皆來自可信來源。

試點週只用生產金鑰與簽名 webhook；staging 權杖不得標成 Live。

冪等鍵與餘額扣款

試行週期間的網路抖動可能會導致您的應用程式發出重複的 HTTP POST 請求。在每次調用時提供獨一無二的 Idempotency-Key 標頭，可確保重複嘗試絕不會觸發雙重計費或重複發送簡訊。請參閱我們的 冪等、重試與資金安全 指南，了解冪等性如何保護您的帳戶。這種保護機制可在不穩定網路環境下，讓您的交易與請求維持一致的系統狀態與正確扣款紀錄。

用一則帶 Idempotency-Key 的 OTP 走完 hold→debit→DLR，證明帳本與回呼同一意圖。

處理狀態回報與 Webhook 失敗

電信業者網路會產生非對應的 DLR 延遲。您的應用程式必須透過內部事件佇列非同步處理 Webhook。若您的接收端點中斷連線或傳回 5xx 錯誤，平台將會啟動帶有指數退避機制的自動重試。使用訊息 UUID 對進站 DLR 酬載維持嚴格的冪等性，以因應閘道重複傳遞的情況。建立監控與告警機制來追蹤佇列堆積與重試狀況，能讓您的團隊第一時間掌握端點的健康狀態與效能。

帳戶門檻與流量擴展

試行週在可預測的財務邊界下導入真實流量動態。帳戶啟用從 20 USD 的預付額度開始，確保餘額不會低於營運保留極限。隨著訊息處理量擴展且整合接近 1,000 USD/月的審查門檻時，營運限制將會動態調整，且不會中斷 API 連線。設定自動儲值警報與動態額度檢查，能讓您的服務在業務快速成長過程中始終保持穩定與順暢營運。

把本次作業寫成可匯出的三欄：時間戳、狀態碼、關聯 ID。值班與財務讀同一匯出，不靠口頭交接。若簽名失敗或 hold 未釋放，先停量再改設定。第二週複盤只認帶證據的列，不認聊天摘要。

從 IOSOR 開始

核發一把生產範圍的金鑰，不要用沙箱 token，並把回呼指到你自己的簽章 webhook URL。用 Idempotency-Key 發一則 OTP 或警示。確認預付 hold、debit 與 DLR 都落在同一意圖。沒有專用金鑰與已驗證簽章的 Live 徽章仍是 setup。

API 事故週：缺少冪等性會導致凍結而非重試風暴 首次扣款前的預付資金保留.

IOSOR 要點

要做：第一個上線週用生產金鑰、簽章 webhook，以及 ledger 裡看得到的一筆預付 hold。

不要：把沙箱 token 接到實流量上，或把未簽章回呼當成試營運將就。