
語言 🇹🇼 繁體中文
概覽
實作
幕後運作
Webhook
使用 FastComments,可以在評論被新增、更新或從我們的系統中移除時呼叫一個 API 端點。
我們透過 HTTP/HTTPS 的非同步 webhooks 來達成這個目的。
什麼是 Webhook 
Webhook 是一種機制,或是兩個系統之間的整合,其中的 "producer" (FastComments) 觸發一個事件 而 "consumer" (您) 則透過 API 呼叫來接收並處理該事件。
支援的事件與資源 
FastComments 僅支援對 Comment 資源的 webhook。
我們支援對評論的建立、刪除以及更新的 webhook。
這些在我們系統中被視為獨立的事件,因而具有不同的語意 並且有不同的 webhook 事件結構。
任意數量的端點都可以從儀表板或透過 API 訂閱相同的事件 (請參閱 透過 API 管理 Webhooks)。每個 webhook 都會獨立傳送。
本機開發設定 
若要進行本機開發,請使用像 ngrok 這樣的工具。
為了簡化系統安全性的維護,本機開發遵循與設定及保護其他環境相同的流程。
步驟 1:將 "localhost" 新增至您帳戶的網域中。
在此處將 "localhost" 新增為網域。
步驟 2:選擇一個 API 金鑰
我們將為您的網域新增 webhook 設定,因此需要一個 API 金鑰。您可以在此處進行設定。
在「Associate with domain」下方 - 選擇您的「localhost」網域。
注意:或者,您可以為所有測試活動和預備環境使用同一個 API 密鑰。只需為「All Domains」新增一個 API 密鑰,並將其命名為「test」之類的名稱。
請確保您已為正式環境網域定義了 API 密鑰。所有其他網域的事件將使用萬用字元(測試)密鑰。
步驟 3:新增您的 Webhook
在執行 ngrok 或類似工具時,在此處為「localhost」設定值。
當點擊 Send Test Payload 時,我們會傳送兩個測試事件,以檢查您是否驗證了 API 金鑰。
驗證通過後,點擊 Save。
步驟 4:新增一則留言
現在您可以新增、編輯或刪除留言,並應該會看到我們使用您的測試 API 金鑰,將事件呼叫傳送至您的本機開發機器。事件可能需要最多 30 秒的延遲才會到達您的機器。
設定 
跟隨在 localhost 上的步驟與在正式環境相同。確保已設定正式環境的網域與 API 密鑰。
首先,前往 Webhooks 管理。此頁面可於 管理資料 -> Webhooks 取得。
此頁面會列出您帳號中的所有 webhook:
點擊 新增 Webhook 以新增。每個 webhook 包含一個 URL、一個評論事件(建立、更新或刪除)、一個域名,以及一個 HTTP 方法:
每個 webhook 皆獨立傳送。您可以將相同的事件發送至多個端點,且範圍設定為 All Domains 的 webhook 會接收所有域名的評論,即使同一事件在特定域名已存在 webhook。相同的 URL、事件與域名不可重複新增。
在儲存之前,點擊 Send Test Payload 以檢查端點是否接受已簽名的請求。請參閱下一節「測試」以取得詳細資訊。
在列表中,您可以編輯、停用、重新啟用或刪除 webhook。停用會保留排隊的事件,直到 webhook 重新啟用;刪除則會丟棄這些事件。
Webhook 也可以透過 API 建立,例如使用 Zapier。這些會在同一列表中顯示,來源標示為 API。請參閱「透過 API 管理 Webhook」以了解更多。
測試 
新的和編輯 webhook 頁面都有一個 Send Test Payload 按鈕,會將請求發送到表單中目前的 URL,無論是否已儲存。Create 和 Update 事件會傳送一個虛擬的 WebhookComment 物件,而測試 Delete 時會傳送僅包含 ID 的虛擬請求主體。
驗證有效負載
測試 webhook 整合時,請確認傳入的請求包含以下標頭:
X-FastComments-Timestamp- Unix 時間戳記(秒)X-FastComments-Signature- HMAC-SHA256 簽名
在引入簽名機制之前建立的 webhook 也會收到包含您 API 密鑰的 token 標頭。新 webhook 則不會。
使用 HMAC 簽名驗證以確保 payload 為真實的。
測試工具
您可以使用像是 webhook.site 或 ngrok 之類的工具,在開發過程中檢查傳入的 webhook payload。
事件類型
- Create Event:當新評論被建立時觸發。
- Update Event:當評論被編輯時觸發。
- Delete Event:當評論被刪除時觸發。
每個 webhook 皆綁定單一事件與單一 HTTP 方法(POST、PUT 或 DELETE)。每個事件在請求主體中包含完整的評論資料(請參閱 Data Structures 了解 payload 格式)。
資料結構 
透過 webhook 傳送的唯一結構是 WebhookComment 物件,以下以 TypeScript 說明。
WebhookComment 物件結構
「Create」事件結構
「create」事件的請求主體是一個 WebhookComment 物件。
「Update」事件結構
「update」事件的請求主體是一個 WebhookComment 物件。
「Delete」事件結構
「delete」事件的請求主體是一個 WebhookComment 物件。
2023 年 11 月 14 日的變更
先前「delete」事件的請求主體僅包含留言 id。現在則包含刪除當下的完整留言內容。
每個鍵值一律都會出現在請求主體中。當留言的某個欄位沒有值時,主體會帶有 null
(布林值為 false,列表為 []),因此每次傳送的資料形狀不會因留言不同而改變。
Run 
當使用者在留言中被標記時,相關資訊會儲存在名為 mentions 的列表中。該列表中的每個物件
具有以下結構。
Run 
badges 列表中的每個項目具有以下結構。徽章類型請參閱徽章指南。
Run 
HTTP 方法
您可以在管理面板中為每種 webhook 事件類型設定 HTTP 方法:
- Create 事件:POST 或 PUT(預設:PUT)
- Update 事件:POST 或 PUT(預設:PUT)
- Delete 事件:DELETE、POST 或 PUT(預設:DELETE)
由於所有請求都包含一個 ID,Create 與 Update 操作預設即為冪等(PUT)。重複相同的 Create 或 Update 請求不應在您那邊建立重複的物件。
請求標頭
每個 webhook 請求都包含以下標頭:
| 標頭 | 說明 |
|---|---|
Content-Type | application/json |
token | 您的 API Secret |
X-FastComments-Timestamp | 請求簽署時的 Unix 時間戳(秒) |
X-FastComments-Signature | HMAC-SHA256 簽名(sha256=<hex>) |
有關驗證 HMAC 簽名的資訊,請參閱安全性與 API 權杖。
安全性與 API 令牌 
FastComments 的 webhook 請求包含多種驗證機制以確保安全。
傳送的標頭
| 標頭 | 說明 |
|---|---|
token | 您的 API Secret(為了向下相容) |
X-FastComments-Timestamp | 請求簽署時的 Unix 時間戳(秒) |
X-FastComments-Signature | 負載的 HMAC-SHA256 簽名 |
HMAC 簽名驗證(建議)
我們強烈建議驗證 HMAC 簽名,以確保 webhook 負載是真實的且未被竄改。
簽名格式: sha256=<hex-encoded-signature>
簽名的計算方式:
- 串接:
timestamp + "." + JSON_payload_body - 以您的 API Secret 作為金鑰計算 HMAC-SHA256
- 將結果以十六進位編碼
驗證範例(Node.js)
const crypto = require('crypto');
function verifyWebhookSignature(req, apiSecret) {
const timestamp = req.headers['x-fastcomments-timestamp'];
const signature = req.headers['x-fastcomments-signature'];
if (!timestamp || !signature) {
return false;
}
// 驗證時間戳是否為近期(5 分鐘內)
const now = Math.floor(Date.now() / 1000);
if (Math.abs(now - parseInt(timestamp, 10)) > 300) {
return false; // 防止重放攻擊
}
// 驗證簽名
const payload = JSON.stringify(req.body);
const expectedSignature = crypto
.createHmac('sha256', apiSecret)
.update(`${timestamp}.${payload}`)
.digest('hex');
return signature === `sha256=${expectedSignature}`;
}
驗證範例(Python)
import hmac
import hashlib
import time
import json
def verify_webhook_signature(headers, body, api_secret):
timestamp = headers.get('X-FastComments-Timestamp')
signature = headers.get('X-FastComments-Signature')
if not timestamp or not signature:
return False
# 驗證時間戳是否為近期
now = int(time.time())
if abs(now - int(timestamp)) > 300:
return False
# 驗證簽名
payload = json.dumps(body, separators=(',', ':'))
message = f"{timestamp}.{payload}"
expected = hmac.new(
api_secret.encode(),
message.encode(),
hashlib.sha256
).hexdigest()
return signature == f"sha256={expected}"
驗證範例(PHP)
function verifyWebhookSignature($headers, $body, $apiSecret) {
$timestamp = $headers['X-FastComments-Timestamp'] ?? null;
$signature = $headers['X-FastComments-Signature'] ?? null;
if (!$timestamp || !$signature) {
return false;
}
// 驗證時間戳是否為近期(5 分鐘內)
$now = time();
if (abs($now - intval($timestamp)) > 300) {
return false;
}
// 驗證簽名
$payload = json_encode($body, JSON_UNESCAPED_SLASHES);
$message = $timestamp . '.' . $payload;
$expectedSignature = 'sha256=' . hash_hmac('sha256', $message, $apiSecret);
return hash_equals($expectedSignature, $signature);
}
舊版驗證方式
包含您 API Secret 的 token 標頭仍會傳送以維持向下相容。然而,我們建議遷移至 HMAC 驗證以提升安全性,因為它可以防止重放攻擊。
透過 API 管理 Webhook 
Webhooks 也可以透過 REST API 管理。像 Zapier 這類整合服務就是透過這種方式訂閱留言事件,而無需操作儀表板,並且遵循 REST Hooks 模式:訂閱、接收事件、取消訂閱。
API 訂閱與儀表板中設定的 webhooks 並存。留言事件會傳送給每個符合其網域的 webhook,每個都是獨立的傳送,無論該 webhook 是以何種方式建立的。
驗證
每個請求都需要在 x-api-key 標頭(或 API_KEY 查詢參數)中提供您的 API Key,並在 tenantId 查詢參數中提供您的租戶 ID。兩者都顯示在儀表板的 API Secret 頁面上。
訂閱
POST https://fastcomments.com/api/v1/webhooks?tenantId=YOUR_TENANT_ID
x-api-key: YOUR_API_KEY
Content-Type: application/json
{
"url": "https://hooks.zapier.com/hooks/catch/123/abc",
"event": "comment-created"
}| 欄位 | 必填 | 說明 |
|---|---|---|
url | 是 | 絕對的 http 或 https URL。 |
event | 是 | comment-created、comment-updated 或 comment-deleted。 |
domain | 否 | 您帳戶設定中的網域。預設為 *,會接收所有網域的事件。 |
method | 否 | POST(預設)、PUT 或 DELETE。 |
回應包含該訂閱:
{
"status": "success",
"webhook": {
"id": "66f1c4c1e7a2b3d4f5a6b7c8",
"url": "https://hooks.zapier.com/hooks/catch/123/abc",
"event": "comment-created",
"domain": "*",
"method": "POST",
"source": "api",
"enabled": true,
"createdAt": "2026-09-08T12:00:00.000Z"
}
}
將相同的 URL 再次訂閱相同的事件與網域時,會回傳現有的訂閱而非建立重複項,因此用戶端可以安全地重試。每個租戶最多可有 50 個 API 訂閱。
列出
GET https://fastcomments.com/api/v1/webhooks?tenantId=YOUR_TENANT_ID
回傳該租戶的所有 webhook,包括在儀表板中管理的那些("source": "dashboard")。可以使用 event、domain 或 source 進行篩選。
取消訂閱
DELETE https://fastcomments.com/api/v1/webhooks/SUBSCRIPTION_ID?tenantId=YOUR_TENANT_ID
刪除訂閱時,也會一併捨棄仍在佇列中的事件。只有透過 API 建立的訂閱才能以這種方式刪除;儀表板 webhook,或您帳戶中不存在的 id,會回應 404 與代碼 not-found。儀表板 webhook 請在 Webhooks 頁面上編輯。
負載與簽署
傳送內容使用與儀表板 webhook 相同的負載(參閱 Data Structures),並以相同的 HMAC 方案簽署(參閱 Security & API Tokens)。API 訂閱永遠不會收到舊版的 token 標頭,因此請改為驗證 X-FastComments-Signature 標頭。
範例負載
GET https://fastcomments.com/api/v1/webhooks/sample-payloads?tenantId=YOUR_TENANT_ID&event=comment-created&limit=3
以傳送內容的確切格式回傳帳戶最近的留言,讓整合服務可以在第一個事件到達之前顯示真實的範例資料。event 為選填且僅做驗證,因為每個事件都傳送相同的留言物件。limit 預設為 3,接受 1 到 10。花費 2 個 API 點數。
{
"status": "success",
"payloads": [
{
"id": "66f1c4c1e7a2b3d4f5a6b7c8",
"urlId": "https://example.com/blog/hello-world",
"commenterName": "Jane Reader",
"comment": "Great article!",
"date": "2026-09-08T12:00:00.000Z",
"approved": true
}
]
}
以 410 Gone 回應
如果 API 訂閱的端點以 HTTP 410 Gone 回應,FastComments 會將其視為取消訂閱:該訂閱會連同其佇列中的事件一起刪除,並且不再嘗試任何後續傳送。在儀表板中設定的 webhooks 永遠不會被自動刪除;對它們而言,410 只是一般的失敗。任何其他失敗狀態會被重試,並最終停用該 webhook,如 How it Works & Handling Retries 中所述。
儀表板
API 訂閱會以來源 API 顯示在 Webhooks 清單中,管理員可以在那裡編輯、停用、重新啟用或刪除它們。
運作方式與重試處理 
系統中對 Comment 物件的所有變更都會觸發一個事件,該事件最終會進入佇列。
初始的 webhook 事件通常會在事件來源發生後約六秒內發送。
你可以在 Webhooks 管理介面中監控此佇列,以防你的 API 故障。
如果對你的 API 的請求失敗,我們會依排程將其重新放入佇列。
該排程為 1 Minute * the retry count。如果呼叫失敗一次,系統將在
一分鐘後重試。如果失敗兩次,則會等待兩分鐘,依此類推。這樣做是為了
避免在你因為負載相關原因而出現故障時,對你的 API 造成過大的負載。
Webhooks 可以從 記錄頁面 取消。
結論
以上即為我們的 Webhooks 文件。
我們希望您覺得 FastComments 的 Webhook 整合容易理解且快速設定。
如果您發現我們的文件有任何遺漏,請在下方讓我們知道。