🟠 首頁 / Web 前端開發 / Webflow電商訂單簡訊通知串接教學

Webflow電商訂單簡訊通知串接教學

發佈時間： 2026-09-11

許多在 Webflow 上營運電子商務的團隊常面臨一項痛點：預設的電子郵件通知容易被收件匣歸類為宣傳郵件或垃圾訊息，顧客無法即時掌握訂單出貨或付款變更進度。相較之下，SMS 簡訊具有較高的即時開啟特性。過去為了將 Webflow 訂單事件轉換為簡訊，多數團隊會求助於無程式碼自動化平台（如 Zapier 或 Make），但隨著訂單量增加，額外產生的月費與任務額度往往成為不小的負擔。

利用現代伺服器端路由架構，我們可以直接透過 Webflow 官方或自託管的伺服器端輕量處理常式（Route Handler），接收 Webflow 產生的訂單狀態變更 Webhook，並使用原生 fetch 呼叫 Twilio 訊息 API。這項作法能消除中間介面的維護負擔，以下將說明完整的架構設計與實作程序。

文章導覽

輕量串接架構：Webhook 與 Route Handler 的協同運作

整套自動化流程的運作核心包含三個節點：

Webflow 電商事件觸發：當顧客下單、訂單付款完成或商家更新履約狀態時，Webflow 會將包含訂單明細的 JSON 酬載以 HTTP POST 方式發送至指定的 Webhook 網址。
中繼 Route Handler：這是一段運行於雲端無伺服器環境（如 Webflow Cloud、Cloudflare Workers、Vercel 等）的輕量後端函式。它負責接收 Webhook、驗證來源合法性、擷取顧客的手機號碼與訂單狀態，並組裝發送文字。
Twilio REST API：Route Handler 向 Twilio 端點發出經過授權的請求，Twilio 接手處理電信網絡投遞，將簡訊送達顧客手機。

這種直接呼叫的方式免除了第三方自動化平台的額外延遲，並且能完全掌握錯誤處理與日誌紀錄。

實作步驟一：建立並配置 Webflow 訂單更新 Webhook

首先需要讓 Webflow 知道何時該發出通知，並指定接收資料的端點。

登入 Webflow 專案後台，前往 Site Settings（網站設定）。
在左側導覽列選擇 Integrations（整合）標籤，並捲動至 Webhooks 區塊。
點擊 Add Webhook，在事件類型（Trigger Type）中選擇 E-commerce: Order Updated 或 E-commerce: Order Fulfilled，視希望發送簡訊的時間點而定。
在 Destination URL 輸入預先準備好的 Route Handler 端點網址，完成儲存。

完成後，Webflow 會在每次觸發條件滿足時，將詳細訂單資料派發至該 URL。

實作步驟二：撰寫 Route Handler 處理常式與 Twilio 串接

在後端處理函式中，主要工作是解析傳入的請求本文，並呼叫 Twilio Messages 端點。參考外部技術教學來源 How to send order status SMS from Webflow e-commerce with Twilio and one route handler 的基本實作邏輯，核心處理流程如下：

export async function handleWebhook(request) {\n  if (request.method !== 'POST') {\n    return new Response('Method Not Allowed', { status: 405 });\n  }\n\n  const payload = await request.json();\n  const orderData = payload.order;\n  \n  // 擷取顧客電話號碼與訂單狀態\n  const customerPhone = orderData?.customerInfo?.phone;\n  const orderStatus = orderData?.status;\n  const orderId = orderData?.id;\n\n  if (!customerPhone) {\n    return new Response('No phone number available', { status: 200 });\n  }\n\n  // 組合簡訊內文\n  const messageBody = `您的訂單 #${orderId} 狀態已更新為：${orderStatus}。感謝您的訂購！`;\n\n  // 呼叫 Twilio REST API\n  const accountSid = process.env.TWILIO_ACCOUNT_SID;\n  const authToken = process.env.TWILIO_AUTH_TOKEN;\n  const fromNumber = process.env.TWILIO_PHONE_NUMBER;\n\n  const twilioUrl = `https://api.twilio.com/2010-04-01/Accounts/${accountSid}/Messages.json`;\n  const authHeader = 'Basic ' + btoa(`${accountSid}:${authToken}`);\n\n  const formData = new URLSearchParams();\n  formData.append('To', customerPhone);\n  formData.append('From', fromNumber);\n  formData.append('Body', messageBody);\n\n  const twilioResponse = await fetch(twilioUrl, {\n    method: 'POST',\n    headers: {\n      'Authorization': authHeader,\n      'Content-Type': 'application/x-www-form-urlencoded'\n    },\n    body: formData\n  });\n\n  if (!twilioResponse.ok) {\n    const err = await twilioResponse.text();\n    return new Response(`Twilio Error: ${err}`, { status: 500 });\n  }\n\n  return new Response('SMS Sent Successfully', { status: 200 });\n}

這段常式不需要額外安裝大型 SDK，透過原生 fetch 就能直接與 Twilio API 溝通，執行效率高且資源消耗極低。

實作步驟三：環境變數管理與 Webhook 安全驗證

在正式部署前，有兩項資安維護重點必須落實：

首先是憑證隔離。絕不可將 TWILIO_ACCOUNT_SID 與 TWILIO_AUTH_TOKEN 直接寫死在程式碼中。這些敏感字串必須儲存於主機環境變數（Environment Variables）內，避免因程式碼版本控制外洩而遭濫發簡訊。

其次是來源驗證防禦。公開的 Route Handler 端點任何人都可能發送偽造的 POST 請求。為防止惡意人士冒充 Webflow 觸發大量簡訊，建議在設定 Webflow Webhook 時加上查詢參數密鑰（如 ?secret=your_token）並在函式中核對，或者驗證 Webflow 發送的簽章標頭。若驗證不符，直接回傳 HTTP 403 阻擋，保護帳戶餘額。

實務限制與例外情境解析

在導入此方案時，技術架構外仍存在兩項明確的商業與法規限制，開發團隊必須預先規劃：

1. 各國電信法規與號碼審查限制：不同國家對於企業商業簡訊有嚴格的合規要求。例如，發送簡訊至美國門號必須完成 A2P 10DLC 品牌與使用情境登記，否則電信商會直接拒收；而在台灣與多數亞洲市場，未帶有特定識別代碼的國際虛擬號碼容易被電信防詐機制直接判定為垃圾簡訊並予以攔截。若未完成在地電信登記，無法保證簡訊能全數送達顧客手機。

2. 網路重試與重複發送（等冪性）風險：Webflow 的 Webhook 機制在接收端回傳超時（通常為數秒內）或非 2xx 狀態碼時，會自動嘗試重新發送。若 Route Handler 成功呼叫了 Twilio，但在向 Webflow 回傳確認時遭遇網路斷線，Webflow 將再次派發相同的事件。如果後端沒有透過資料庫比對「該訂單狀態事件是否已經發送過」，消費者可能會在短時間內收到多封重複的通知簡訊，造成體驗不佳與通訊費用浪費。

評估導入這項方案時，建議先於測試環境完整驗證電話號碼格式（E.164 規範）解析，並確認目標客群所在地區的電信管制門檻，才能建立穩定且經濟的訂單通訊管道。