首頁 › 名詞百科 › Webhook（事件回呼）

數位與系統・Knowledge

Webhook（事件回呼）

事情一發生，對方系統主動把通知送到您指定的網址；LINE 官方帳號收到訊息、客人加好友、付款完成，都是靠它即時傳進您的後台。

關鍵事實

方向：由事件來源主動推送到您的接收網址，與您主動呼叫 API 查詢的方向相反
常見來源：LINE 訊息平台、金流服務、電子發票平台、表單與預約系統
接收端：一支放在您後端的程式，網址需用 HTTPS，收到後立即回應再慢慢處理
驗證：以來源提供的簽章或金鑰驗證每一筆通知，避免偽造請求寫進資料庫
重送與去重：來源在沒收到回應時可能重送同一事件，接收端要用事件識別碼去重
資料歸屬：通知帶進來的好友識別碼與對話內容屬個人資料，存在業主名下資料庫並依《個人資料保護法》設計告知與權限

白話解釋

Webhook 可以想成「事件發生時對方打給您的電話」。

平常是您的系統主動去問對方「有沒有新訊息」，Webhook 把方向反過來：客人在 LINE 官方帳號傳訊息、加好友、點選單，LINE 的平台就立刻把這個事件送到您事先登記的網址，您的後端程式收到後決定要自動回覆、寫進客戶主檔還是轉給人工。

金流付款完成、發票開立成功也用同樣的方式通知。對業主的意義是「即時」與「不用一直輪詢」，代價是您得有一支穩定、可驗證、能處理重送的接收程式；它掛掉，通知就漏接，而且對方不會替您補。

你什麼時候會遇到它

開發廠商的報價單出現「Webhook 接收端」或「事件回呼端點」；LINE 開發者後台要求填寫 Webhook 網址並通過驗證；金流或發票服務後台有「通知網址」欄位；上線後客人說「我傳了訊息沒人回」，查下去發現接收程式當時沒回應。

常見情境與對策

LINE 官方帳號的自動回覆偶爾沒反應——檢查接收端的錯誤紀錄與回應時間，確認收到事件先立即回應再處理耗時工作，並設定失敗通知；必要時改成佇列處理。
付款成功但訂單狀態沒更新——核對金流服務的通知紀錄與接收端紀錄，確認簽章驗證沒有誤擋、重送事件有被正確去重，並補一條定時對帳作為保險。
更換主機或網域，通知全部中斷——在來源後台更新通知網址並重新驗證，新舊網址並行一段時間，確認新端點穩定收到事件後再下線舊的。

LINE 諮詢

把LINE 官方帳號串接的現況與需求傳過來，先免費書面初判。

傳什麼: 現有網站網址與後台權限還沒有網站也能先談
商品或服務清單、作業流程說明表單樣張或試算表皆可
需求清單一句話也行
多久回: 週一至週五 09:00–18:00 依序回覆；LINE 全天可傳資料
下一步: 免費書面初判
約時間細談
委任開發

先傳資料做初判，需要時再約時間細談

加 LINE 諮詢LINE 官方帳號串接，偉騰統包開發

程序怎麼走

盤點事件：列出要接收的事件種類與各自要觸發的動作，例如訊息進來自動回覆、加好友建立客戶主檔、付款完成更新訂單。
建立接收端：在後端建立 HTTPS 端點，收到請求先驗證簽章、立即回應，再把事件丟進處理流程，避免來源判定逾時。
處理重送與去重：以事件識別碼記錄已處理的通知，重送時直接略過，確保同一筆付款或訊息不會被處理兩次。
測試與監控：在測試帳號走過每一種事件，上線後記錄每筆通知的結果，失敗時通知負責人，並定期與來源的紀錄對帳。
交付與權限：接收端程式、來源後台的設定與資料庫都在業主名下，交付文件寫明網址、金鑰保存位置與更換方式。

先看清楚

Webhook 的接收端等於對外開了一扇門，沒有驗證簽章就等於任何人都能假裝是 LINE 或金流往您的資料庫寫東西。另一個常被忽略的是「立即回應」：接收端若等所有工作做完才回應，來源會判定逾時並重送，重送又沒去重，同一則訊息就會回覆兩次、同一筆付款會入帳兩次。網址與金鑰屬機密，不放在前端程式或共用文件裡。

常見錯誤

接收端不驗證簽章，偽造的請求被當成真實事件寫進系統
收到事件先做完所有工作才回應，來源逾時重送，訊息重複回覆、付款重複入帳
接收端沒有監控，主機重啟後通知漏接好幾天才被客人發現

行動前自查清單

接收網址使用 HTTPS，且在來源後台完成驗證
每筆通知都驗證簽章或金鑰，驗證失敗的請求有紀錄
收到事件先立即回應，耗時工作改以佇列或背景處理
以事件識別碼去重，重送事件不會重複處理
通知失敗有告警，定期與來源紀錄對帳
網址、金鑰與資料庫都在業主名下，交付文件寫明更換方式

常見問題