---
title: "Webhook 完整教學：從零入門到 WhatsApp 整合"
description: "想了解 Webhook 是什麼？本文由淺入深解說 Webhook 原理與設定教學，並示範如何透過 Webhook 對接 WhatsApp，實現自動化訂單通知、CRM 同步及客服流程！"
canonical: "https://sleekflow.io/zh-hk/blog/webhook-tutorial"
html_lang: "zh-hk"
date_modified: "2026-07-17T06:38:43.176Z"
og_title: "Webhook 教學指南：由淺入深解說原理、設定與 WhatsApp 應用"
og_description: "想了解 Webhook 是什麼？本文由淺入深解說 Webhook 原理與設定教學，並示範如何透過 Webhook 對接 WhatsApp，實現自動化訂單通知、CRM 同步及客服流程！"
og_image: "https://images.ctfassets.net/tu2uwzoyozk8/2OEW2cCCS13i3dPPM34TbR/a24ebc682808ed0cce01bd631cb36aa9/TC.jpg?w=1200&q=90"
---

```json
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Webhook 教學指南：由淺入深解說原理、設定與 WhatsApp 應用",
  "description": "想了解 Webhook 是什麼？本文由淺入深解說 Webhook 原理與設定教學，並示範如何透過 Webhook 對接 WhatsApp，實現自動化訂單通知、CRM 同步及客服流程！",
  "url": "https://sleekflow.io/zh-hk/blog/webhook-tutorial",
  "dateModified": "2026-07-17T06:38:43.176Z",
  "image": "https://images.ctfassets.net/tu2uwzoyozk8/2OEW2cCCS13i3dPPM34TbR/a24ebc682808ed0cce01bd631cb36aa9/TC.jpg?w=1200&q=90",
  "breadcrumb": {
    "@type": "BreadcrumbList",
    "itemListElement": [
      {
        "@type": "ListItem",
        "position": 1,
        "name": "Home",
        "item": "https://sleekflow.io/zh-hk"
      },
      {
        "@type": "ListItem",
        "position": 2,
        "name": "Blog",
        "item": "https://sleekflow.io/zh-hk/blog"
      },
      {
        "@type": "ListItem",
        "position": 3,
        "name": "Webhook 教學指南：由淺入深解說原理、設定與 WhatsApp 應用",
        "item": "https://sleekflow.io/zh-hk/blog/webhook-tutorial"
      }
    ]
  }
}
```

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

*Khloe Ho — Assistant Marketing Manager, GCR*

**Webhook 教學**是不少香港企業數位化轉型過程中繞不開的一環。無論是電商訂單通知、CRM 資料同步，還是 [<u>WhatsApp 自動化客服</u>](https://sleekflow.io/zh-hk/blog/whatsapp-chatbot)流程，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 如何結合付款流程，可參考[ <u>WhatsApp 收款完整指南</u>](https://sleekflow.io/zh-hk/blog/whatsapp-payment-hk)。

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

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

這個整合解決了香港銷售與客服團隊之間的資訊斷層問題。銷售在 CRM 完成交易後，客服端的 WhatsApp 對話管理即時同步更新，確保團隊協作無縫銜接，客戶體驗保持一致。更多客戶生命週期管理的實踐，可參考[ <u>SleekFlow 客戶生命週期管理指南</u>](https://sleekflow.io/zh-hk/blog/lifecycle-management)。

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

**觸發事件：** 庫存管理系統偵測到庫存量低於閾值 → **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[ <u>Flow Builder 自動化流程</u>](https://sleekflow.io/zh-hk/blog/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 支援的事件類型**包括：訊息已送達、訊息狀態更新（已讀/未讀）、對話已指派至客服人員、客戶標籤新增或更新、付款連結已完成付款、自動化流程已觸發完成。企業可將上述任一事件即時推送至 [<u>HubSpot</u>](https://sleekflow.io/zh-hk/blog/hubspot-contact-sync)、[<u>Salesforce</u>](https://sleekflow.io/zh-hk/blog/salesforce-integration)、Google Sheets 或自建的內部系統，實現跨平台資料同步。

**入站觸發**則允許外部系統（如 Shopify、Stripe）通過 Webhook 向 SleekFlow 傳送事件，觸發 SleekFlow 內的自動化流程，例如啟動[ <u>WhatsApp AI Agent</u>](https://sleekflow.io/zh-hk/blog/whatsapp-ai-agent) 回覆序列或更新客戶對話標籤。

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

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

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

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

這個自動化鏈路完全不需要人手介入，整個流程從訂單確認到客戶收到 WhatsApp 通知，通常在 30 秒內完成。如需了解 SleekFlow 更多[ <u>WhatsApp 聊天機械人</u>](https://sleekflow.io/zh-hk/blog/whatsapp-chatbot) 及自動化功能，歡迎參閱相關指南。

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

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

無論你是希望將 Shopify 訂單自動化連接至 WhatsApp 通知，還是將 HubSpot 的 CRM 狀態變更即時同步至客服對話，SleekFlow 都能作為你的[ <u>WhatsApp 自動化核心工具</u>](https://sleekflow.io/zh-hk/blog/best-whatsapp-automation-tool)，省去繁複的工程資源投入。

[<u>**立即預約 SleekFlow 示範**</u>](https://sleekflow.io/book-a-demo)，了解 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 行銷成效，歡迎參閱更多資源。
