Webhook 教學指南：由淺入深解說原理、設定與 WhatsApp 應用

Webhook 教學是不少香港企業數位化轉型過程中繞不開的一環。無論是電商訂單通知、CRM 資料同步，還是 WhatsApp 自動化客服流程，Webhook 都是讓不同系統之間「即時對話」的核心技術。本文將由淺入深，帶你全面了解 Webhook 的運作原理、設定步驟，以及如何在香港業務場景中善用 Webhook 提升營運效率。

Webhook 是什麼？

Webhook 是一種讓不同軟件系統在特定事件發生時，自動互相傳送資料的技術機制。例如，當客戶在網店完成付款，Webhook 可即時通知 SleekFlow，自動向客戶發送 WhatsApp 確認訊息，整個過程無需人手介入。

以一個香港企業日常運作的例子來說明：想像你的客服主管不需要每隔五分鐘查看訂單系統，而是由系統主動在每一筆新訂單確認後，立即向你的客服平台發出通知，並自動觸發後續行動。這就是 Webhook 的本質——事件驅動、即時推送、無需人手輪詢。

Webhook 的運作原理：「事件觸發、即時推送」

Webhook 的技術架構建立在「事件驅動」的邏輯之上。當平台 A 發生某個預設事件（例如新訂單建立、表單提交、付款確認），平台 A 會即時向一個預先設定好的 URL 發送一個 HTTP POST 請求，請求中包含事件的詳細資料，即所謂的「Payload（數據負載）」。平台 B 的伺服器收到這個請求後，會根據其中的資料執行對應的動作，例如發送 WhatsApp 訊息、更新 CRM 聯絡人狀態，或記錄資料至試算表。

要理解 Webhook，有三個核心概念需要掌握。Payload 是事件觸發時附帶的 JSON 格式資料，包含訂單編號、客戶資料、付款金額等具體內容；Endpoint URL 是接收方（平台 B）提供的目標地址，發送方將資料 POST 至此處；Listener（監聽器）則是接收端持續等待並處理傳入請求的程序。整個流程的關鍵在於：資料是由來源系統主動推送，而非目標系統定期主動查詢。

Webhook 與 API 有什麼分別？

這是香港開發者社群及業務運營團隊最常提出的概念問題。兩者最根本的差異在於觸發方式：

比較維度	API（應用程式介面）	Webhook
觸發方式	由應用程式主動發出請求（拉取模式）	由事件自動觸發推送（推送模式）
通訊方向	雙向：請求 → 回應	單向：事件發生 → 即時通知
資源消耗	需定期輪詢，消耗較高	僅在事件發生時觸發，效率更高
適用場景	查詢資料、執行複雜操作	即時通知、狀態更新、跨平台同步
技術難度	需要身份驗證和錯誤處理邏輯	設定較簡單，多數平台提供圖形介面

簡單而言：API 是「你問我答」，Webhook 是「有事我通知你」。在真實的業務自動化場景中，兩者往往同時存在、互相配合。以 WhatsApp 自動化為例，Webhook 負責即時監聽並接收新訊息或對話事件，而 API 呼叫則用於主動發送外發訊息。

Webhook 的常見應用場景：香港企業最實用的五個案例

在正式進入設定教學之前，先了解 Webhook 如何真正解決香港企業的業務問題，有助於你在實施時更清晰地定義自己的需求。

場景一：電商訂單確認自動發送 WhatsApp 通知

觸發事件： Shopify 訂單建立 → Webhook 推送至 SleekFlow → 自動執行：系統即時向客戶發送 WhatsApp 訊息，附上訂單編號及預計送達時間。

這個場景對香港高流量電商及跨境物流企業尤為實用。過去需要客服人員逐單核對並手動回覆的工作，通過 Webhook 串接，可在訂單確認後數秒內自動完成，大幅節省人力成本，亦提升客戶對品牌的第一印象。

場景二：表單提交後自動觸發 WhatsApp 跟進

觸發事件： HubSpot 或 Typeform 的潛在客戶表單提交 → Webhook 推送至 SleekFlow → 自動執行：銷售代表自動被指派，並在 60 秒內向潛在客戶發出 WhatsApp 首次聯繫訊息。

香港 B2B 銷售團隊普遍面臨的痛點是：潛在客戶提交表單後，往往需要等待數小時甚至數天才獲回覆，大幅降低成交率。Webhook 自動化可以將首次回應時間壓縮至 60 秒以內，直接提升轉換率。

場景三：付款成功後自動啟動客戶服務流程

觸發事件： Stripe 或 PayMe 付款確認 → Webhook 推送至 SleekFlow → 自動執行：自動啟動客戶入門 WhatsApp 序列，引導客戶完成下一步。

這個場景尤其適合香港的 SaaS 訂閱企業及專業服務公司。付款完成後，Webhook 即時觸發 SleekFlow，自動發送歡迎訊息、服務說明，以及後續使用指引，無需人手介入。如需進一步了解 SleekFlow 如何結合付款流程，可參考 WhatsApp 收款完整指南。

場景四：CRM 聯絡人狀態更新同步至 WhatsApp 對話紀錄

觸發事件： HubSpot 交易階段變更為「Closed Won」→ Webhook 推送至 SleekFlow → 自動執行：客戶自動進入售後 WhatsApp 培育序列，聯絡人記錄同時完成標籤更新。

這個整合解決了香港銷售與客服團隊之間的資訊斷層問題。銷售在 CRM 完成交易後，客服端的 WhatsApp 對話管理即時同步更新，確保團隊協作無縫銜接，客戶體驗保持一致。更多客戶生命週期管理的實踐，可參考 SleekFlow 客戶生命週期管理指南。

場景五：庫存警報觸發供應鏈通知訊息

觸發事件：庫存管理系統偵測到庫存量低於閾值 → Webhook 通知運營團隊 → 自動執行：透過 WhatsApp 群組發出補貨警示，觸發補貨工作流程。

對香港批發、分銷及零售業而言，庫存管理的實時性至關重要。通過 Webhook 整合，系統可在庫存觸底前主動發出警告，避免缺貨損失。

Webhook 教學：從零開始設定的完整步驟

以下提供三種設定方法，涵蓋從無技術背景的業務團隊到開發人員的不同需求，每種方法均按統一格式編排，方便對照選用。

方法一：使用 Zapier 設定 Webhook（無需編程）

適合對象：行銷、營運或客服團隊，無技術背景但需要連接不同平台

步驟一：在 Zapier 建立新 Zap 登入 Zapier → 點選「Create Zap」→ 在觸發器（Trigger）搜尋欄選擇「Webhooks by Zapier」→ 選擇「Catch Hook」模式。Zapier 將為你自動生成一個專屬的 Webhook URL。

步驟二：複製 Webhook URL 並貼入來源平台將 Zapier 生成的 Webhook URL 複製至你的來源平台（如 Shopify、HubSpot、Typeform）的 Webhook 設定欄位，並指定觸發條件（例如：訂單建立、表單提交）。

步驟三：執行測試觸發，確認資料接收正確在來源平台手動觸發一個測試事件（例如提交一份測試表單），返回 Zapier 確認 Webhook 已接收到完整的 JSON 資料 payload。請仔細核對欄位名稱與資料格式，確保後續步驟能正確引用。

步驟四：設定動作（Action）在 Zapier 的 Action 步驟選擇目標平台，配置要執行的具體操作（例如：向 SleekFlow 傳送客戶資料以觸發 WhatsApp 訊息、新增 CRM 記錄、更新 Google Sheets 等）。

步驟五：啟動 Zap 並監控運行狀態開啟 Zap 的啟用開關，在 Zapier 的「Task History」頁面確認後續觸發是否成功。建議設置失敗通知提醒，以便及時介入處理異常。

方法二：在 SleekFlow 直接設定 Webhook 觸發器

適合對象：已使用 SleekFlow 的企業，希望將 WhatsApp 對話事件推送至外部系統

SleekFlow 原生支援 Webhook 出站（Outbound Webhook），可將平台內的對話事件即時推送至你的 CRM、數據倉儲或自建 API 端點。如需了解 SleekFlow Flow Builder 自動化流程的完整功能，可參考相關介紹。

步驟一：進入 SleekFlow 的整合設定頁面登入 SleekFlow 管理後台 → 導航至「設定」→「整合」→「Webhook」。

步驟二：新增 Webhook 端點 URL 點選「新增 Webhook」→ 在 URL 欄位填入你的目標系統接收地址（你的 CRM、數據倉儲或自建 API endpoint）。注意：端點 URL 必須使用 HTTPS，系統不接受 HTTP 明文地址。

步驟三：選擇觸發事件類型從 SleekFlow 支援的事件列表中選擇觸發條件，例如：訊息送達、對話已指派、客戶標籤更新、付款連結完成、流程完成等，根據你的業務需求靈活組合。

步驟四：設定驗證金鑰（Secret Key）為 Webhook 設定一個 Secret Key，確保接收端能夠驗證請求來源為 SleekFlow，有效防止未授權的偽造請求。

步驟五：測試並確認 Payload 格式使用 SleekFlow 內建的「發送測試事件」功能，在目標系統或 Webhook 測試工具（如 webhook.site）確認接收到的 JSON 結構符合預期，確保所有欄位均能正確映射至目標系統。

方法三：開發者自建 Webhook 接收端點（進階）

適合對象：技術開發人員，需要完全自主控制 Webhook 接收邏輯的企業

自建 Webhook 接收端點需符合以下基本要求。首先，端點必須使用 HTTPS，所有主流企業平台（包括 SleekFlow、Shopify、Stripe）均拒絕向非加密的 HTTP 地址發送 Webhook 請求。其次，接收端必須在超時窗口內返回 HTTP 200 OK，通常為 5 至 30 秒，否則發送方會將其視為傳送失敗並觸發重試。第三，需實施冪等性（Idempotency）處理，將已處理的事件 ID 儲存記錄，對重複事件直接忽略，防止訂單重複觸發或訊息重複發送等問題。

以下為 Node.js 的最小化接收骨架，供開發者參考：

const express = require('express');

const crypto = require('crypto');

const app = express();

app.use(express.json());

app.post('/webhook', (req, res) => {

// 1. 驗證簽名

const signature = req.headers['x-sleekflow-signature'];

const expectedSig = crypto

.createHmac('sha256', process.env.WEBHOOK_SECRET)

.update(JSON.stringify(req.body))

.digest('hex');

if (signature !== expectedSig) {

return res.status(401).send('Unauthorized');

}

// 2. 立即回應 200，避免超時

res.status(200).send('OK');

// 3. 非同步處理業務邏輯

processEvent(req.body);

});

function processEvent(payload) {

const eventId = payload.event_id;

// 實施冪等性檢查，確認 eventId 是否已處理

// 執行業務邏輯...

}

app.listen(3000);

以 Python（Flask）為框架的接收端骨架邏輯類似，核心步驟同樣是：驗證 HMAC 簽名 → 即時回應 200 → 非同步執行業務邏輯。

Webhook 安全性：香港企業必須注意的四個防護措施

對香港企業而言，尤其是處理客戶個人資料或付款資訊的場景，安全配置是合規運作的必要條件。

一、使用 HTTPS 端點，拒絕明文 HTTP 請求

所有 Webhook 接收端點必須使用 HTTPS。明文 HTTP 傳輸會讓 Payload 中的客戶資料、訂單詳情及系統資訊暴露於網路攔截的風險之下。SleekFlow、HubSpot、Shopify 等企業級平台均強制要求目標端點使用 HTTPS，若你的接收端仍為 HTTP，請求將直接被拒絕。

二、簽名驗證：確保請求來自可信來源

主流企業平台在發送 Webhook 時，會為每個 Payload 附加一個 HMAC 簽名雜湊值（通常放置於請求標頭）。接收端在處理任何事件前，應先驗證此簽名：將收到的 Payload 與共享密鑰（Secret Key）進行 HMAC 運算，然後與標頭中的簽名值比對。若兩者不符，應立即拒絕請求，不執行任何後續操作。這個步驟能有效防止第三方偽造 Webhook 請求。

三、設定白名單 IP 地址

部分企業平台（包括 Shopify 及 Stripe）會公開其 Webhook 出站 IP 範圍。在伺服器防火牆或反向代理層配置 IP 白名單，只接受來自這些可信 IP 的請求，可進一步降低未授權存取的風險。

四、實施冪等性處理，防止重複事件執行

網路重試機制可能導致同一 Webhook 事件被多次傳送。若不加以處理，可能出現重複扣款、重複發送 WhatsApp 訊息等嚴重問題。最佳實踐是在接收端維護一個已處理事件 ID 的記錄（可儲存於資料庫或緩存），每次收到事件前先核查 ID 是否已存在，若是則直接返回成功而不執行業務邏輯。

為什麼 WhatsApp Webhook 整合需要官方 API 合作夥伴？

這是許多企業在規劃 WhatsApp 自動化時必須了解的重要限制。WhatsApp 的 Webhook 基礎架構僅開放給通過 Meta 商業驗證、並接入官方 Cloud API 或 On-Premises API 的合作夥伴。個人版 WhatsApp 及免費版 WhatsApp Business App 均不支援 Webhook 功能。

整合方式	WhatsApp Webhook 存取	技術門檻	合規性
個人版 / Business App	不支援 Webhook	—	不適用企業自動化
自行申請 Cloud API	需通過 Meta 審核，配置複雜	高（需工程師資源）	需獨立維護合規架構
透過 SleekFlow BSP 接入	開箱即用，圖形介面設定	低（無需編程）	Meta 官方認證，合規保障完整

這意味著，若企業希望真正實現「WhatsApp 事件觸發 Webhook 自動化」，必須透過 Meta 授權的業務解決方案供應商（BSP）進行整合，而不能依賴個人版應用程式。

SleekFlow Webhook 的具體能力範圍

SleekFlow 同時支援出站 Webhook（Outbound Webhook）與入站觸發（Inbound Trigger）兩種模式。

出站 Webhook 支援的事件類型包括：訊息已送達、訊息狀態更新（已讀/未讀）、對話已指派至客服人員、客戶標籤新增或更新、付款連結已完成付款、自動化流程已觸發完成。企業可將上述任一事件即時推送至 HubSpot、Salesforce、Google Sheets 或自建的內部系統，實現跨平台資料同步。

入站觸發則允許外部系統（如 Shopify、Stripe）通過 Webhook 向 SleekFlow 傳送事件，觸發 SleekFlow 內的自動化流程，例如啟動 WhatsApp AI Agent 回覆序列或更新客戶對話標籤。

SleekFlow 的 Webhook 整合支援以下主流平台：Shopify（訂單、發貨及客戶事件）、HubSpot（聯絡人及交易屬性變更）、Salesforce（物件更新觸發器）、WooCommerce（訂單生命週期事件）、Stripe（付款成功與失敗事件）、Typeform 及 JotForm（表單提交事件），以及自訂 HTTP 端點目的地（用於對接企業自家的內部私有系統）。對於不在原生名單中的平台，亦可透過 Zapier 和 Make 的連接器，將整合能力延伸至超過 5,000 個第三方應用程式。

實際整合案例：Shopify × SleekFlow × WhatsApp 全自動訂單通知流程

以下是一個香港電商企業的完整自動化鏈路，展示 Webhook 如何在真實場景中串聯多個系統：

客戶在 Shopify 完成訂單付款 → Shopify 即時觸發 Webhook，將訂單資料 POST 至 SleekFlow 的接收端點
SleekFlow 解析 Payload → 系統提取訂單編號、客戶姓名、訂購商品及付款金額等欄位
自動發送個人化 WhatsApp 訊息 → 客戶在訂單確認後數秒內收到包含訂單詳情及預計送達時間的 WhatsApp 通知
對話記錄至 SleekFlow CRM → 本次互動自動記錄至客戶檔案，標籤「已發送訂單確認」
條件判斷：已讀回執監控 → 若 2 小時內訊息未顯示「已讀」，系統自動觸發跟進序列，確認客戶已收到訊息

這個自動化鏈路完全不需要人手介入，整個流程從訂單確認到客戶收到 WhatsApp 通知，通常在 30 秒內完成。如需了解 SleekFlow 更多 WhatsApp 聊天機械人及自動化功能，歡迎參閱相關指南。

立即用 SleekFlow 建立你的第一個 Webhook 自動化流程

Webhook 的真正價值，不在於技術本身，而在於它能夠讓你的業務系統在正確的時機，自動對正確的客戶做出正確的回應。SleekFlow 作為 Meta 官方授權的 WhatsApp BSP，提供完整的 Webhook 入站與出站支援，圖形化介面讓無技術背景的業務團隊同樣能夠輕鬆設定，而開發者亦可透過平台 API 進行深度客製化整合。

無論你是希望將 Shopify 訂單自動化連接至 WhatsApp 通知，還是將 HubSpot 的 CRM 狀態變更即時同步至客服對話，SleekFlow 都能作為你的 WhatsApp 自動化核心工具，省去繁複的工程資源投入。

立即預約 SleekFlow 示範，了解 Webhook 整合如何幫助你的業務實現真正的自動化。

常見問題

Webhook 與 API 整合，哪一個更適合我的業務？

Webhook 最適合用於「即時事件通知」的場景。當其他系統發生特定事件（例如：客戶建立訂單、成功收到付款、訊息已送達）時，若你的系統需要立即做出相應反應，Webhook 就是最佳選擇。相反，API 則更適合用於需要「按需查詢數據」或執行複雜、多步驟操作的場景。大多數完善的系統整合都會同時結合兩者：利用 Webhook 來監聽即時事件，再透過 API 進行數據檢索與執行具體操作。以 WhatsApp 自動化為例，Webhook 主要負責實時監聽並接收新訊息事件，而 API 呼叫則用於發送外發訊息（Outbound Messages）。

設定 Webhook 一定需要技術人員嗎？

不需要。非技術團隊完全可以利用 Zapier 或 Make（前稱 Integromat）等無程式碼（No-code）中介平台來設定 Webhook。這些平台提供了直覺的圖形化介面，讓你無需編寫任何程式碼，就能輕鬆將 Webhook 觸發器（Triggers）與特定的後續操作（Actions）串連起來。此外，SleekFlow 的原生 Webhook 介面也提供了可視化的設定用戶介面（UI），同樣不需要任何編程知識。技術開發人員的參與，主要是在需要開發自家自訂端點（Custom Endpoints）、進行複雜的數據負載轉換（Payload Transformation），或面臨高流量、對穩定性有極高要求的企業級場景下才必不可少。

Webhook 傳送失敗了怎麼辦？資料會遺失嗎？

大多數企業級平台針對傳送失敗的 Webhook 都設有「自動重試機制」，通常會在 24 至 72 小時內以指數級的時間間隔（Exponential Intervals）嘗試重新發送。SleekFlow 的 Webhook 系統亦內建了完整的傳送狀態日誌（Logs）與失敗告警提示。為了全面防止數據遺失，業界的最佳實踐是在接收端建立一個「事件隊列（Event Queue）」，並在開始處理前先記錄所有傳入的 Webhook 數據負載（Payloads）。這樣一來，即使下游系統暫時處理失敗，仍然可以隨時重新播放（Replay）並復原數據，確保資訊不漏失。

WhatsApp Business App 可以使用 Webhook 嗎？

不可以。免費的手機應用程式（WhatsApp Business App）並不支援 Webhook 功能。如果希望透過 Webhook 獲取 WhatsApp 的即時事件數據——包括訊息送達狀態、接收訊息內容以及對話的元數據（Metadata）——就必須使用 WhatsApp Business API。而要對接 API 級別，需要透過 Meta 授權的業務解決方案供應商（BSP，例如 SleekFlow）進行整合。這是免費版 App 與 API 級別之間最核心的底層架構與功能分別。如需進一步了解 AgentFlow AI Agent 如何在 API 層實現更深度的 WhatsApp 自動化，可參閱相關介紹。

SleekFlow 支援哪些平台的 Webhook 整合？

SleekFlow 支援與多個國際及本地主流平台的原生 Webhook 整合，包括：Shopify（訂單、發貨履行及客戶事件）、HubSpot（聯絡人及交易屬性變更）、Salesforce（物件更新觸發器）、WooCommerce（訂單生命週期事件）、Stripe（付款成功與失敗事件）、Typeform 及 JotForm（表單提交事件），以及自訂 HTTP 端點目的地（用於對接企業自家的內部私有系統）。如果你的平台不在上述的原生名單中，亦可透過 Zapier 和 Make 的連接器，將 Webhook 的串接能力輕鬆延伸至 5,000 多個第三方應用程式。如需了解 SleekFlow 如何協助企業全面提升 WhatsApp 行銷成效，歡迎參閱更多資源。

Webhook 完整教學：從零入門到 WhatsApp 整合