簡訊
它到底能做什麼
憑證，加密存放
您的 Twilio SID 和 token 加密存放，而且不會再顯示第二次；您的發送者識別、Messaging Service 和各項登記，維持您當初設定的樣子。
貨真價實的雙向
入站簡訊透過帶加密簽章的 webhook 進來，落地時就是已分流的對話；狀態回呼會沿著只能往前走的「已送出 → 已送達」階梯推進每一則訊息——已確認的送達絕不會倒退。
分段數就寫在對話上
每一次發送都會記錄實際送出了幾段簡訊——您的 Twilio 帳單，在對話裡就解釋得清楚。
內建驗證
一次性驗證碼的電話驗證走 Twilio Verify——驗證碼由 Twilio 產生、發送和檢查；我們什麼都不存。
技術細節
分段算的是錢——所以它住在伺服器端
成本只有一個真相來源
分段計算跑在伺服器上，而且只有一份。放在用戶端的副本一定會和實際帳單產生落差——而且落差的方向永遠是讓人安心的那一邊。
把帳單變三倍的那個 ş
只要一個字元不在 GSM 字母表裡，整則訊息就掉到 70 字元一段。編輯器在您送出之前就知道這件事——161 個 GSM 字元算的是兩段各 153，不是 160 加 1。
連跳脫字元對都算進去
^、{、} 和 € 這類字元在 GSM 編碼裡一個要算兩單位，表情符號在 UCS-2 裡也算兩單位——計數器照電信商的算法算。
優先走 Messaging Service
只要您設定過 Twilio Messaging Service，發送就會優先走它，而不是直接用裸號碼——沿用您的號碼池、黏性發送者和合規設定，而不是繞過它們。
驗證，交給代管的做法
電話驗證使用 Twilio Verify：驗證碼由 Twilio 產生、發送和檢查，並依客戶的語言在地化——沒有 OTP 密鑰要保管，也沒有驗證碼會外洩。
失敗回來時有名有姓
被拒絕的發送會帶著 Twilio 真正的理由回來——認證、地區權限、未驗證的試用號碼——直接呈現給操作人員，而不是洗成一句籠統的錯誤。
設定方式
串接方式
貼上您的憑證
SID 和 token 靜態加密，設定的當下就驗證。
挑選您的發送者
您的號碼和發送者識別會以管道的形式出現，可以依部門分流。
踩著煞車發簡訊
行銷活動在發送的當下逐一核對每位收件人的同意——週二退訂的人，週三就會被跳過，並記下跳過的理由。
安全與保證
無聊但管用的保證
入站在密碼學上就是您的
每一個入站 webhook 都用 Twilio 的簽章機制驗證——對完整網址和排序過的內容做 HMAC，金鑰是您的帳號 token。一個沒有簽章的「入站簡訊」，等於在別人的收件匣上開了一扇門；這扇門我們關著。
祕密當成祕密處理
SID 和 token 靜態加密，只出現在認證標頭裡，絕不寫進日誌，也絕不回聲到錯誤訊息中。
同意，核兩次
行銷活動在建立受眾時核一次同意，發送的當下再逐則核一次——週二退訂的人，週三就會被跳過，跳過這件事有紀錄，也有理由。
連回條都有簽章
送達狀態回呼和入站訊息一樣要驗簽章，用的是您自己的金鑰——一個沒有簽章的狀態端點，等於讓任何人都能把您的訊息標成「已送達」，這比假訊息更安靜，也更糟，因為根本沒人會去查。
不加修飾的細則
邊界，寫清楚
不支援 MMS
多媒體訊息沒有實作——附件會帶著具名的理由失敗，而不是被默默丟掉，但它就是失敗，我們直說。
英數字發送者 = 單向
品牌文字發送者收不到回覆——這是簡訊的物理法則，編輯器知道這件事。