Telegram Webhook 回覆：放進回應主體，還是另行呼叫 sendMessage？

Telegram 容許在 webhook 的 HTTP 回應內呼叫 sendMessage 等 Bot API 方法，但官方明確說明：應用程式無法知道這次呼叫是否成功，也無法取得結果。如果需要儲存發送後的訊息識別碼，或處理明確的 API 錯誤，應另行發出 Bot API 請求。回傳 200 OK 確認收到 webhook，不等於確認聊天回覆已發送。

重點

• HTTP 接收確認、API 執行結果、用戶已讀，是三個不同層次。
• 在回應內嵌入方法可以減少一次請求，但拿不到方法結果。
• 後續工作依賴訊息識別碼或發送紀錄時，宜另行呼叫 sendMessage。
• UnifyPort 的規格不同：webhook 回應主體會被捨棄，發送訊息需要獨立 API 呼叫。

Telegram webhook 回應可以做甚麼？

Telegram Bot API 官方文件說明，可在 webhook 回應中使用 application/json、application/x-www-form-urlencoded 或 multipart/form-data 傳遞參數，再以 method 指定方法。

例如，應用程式可在 JSON 回應內提供 method: sendMessage，以及相應的 chat_id 和 text。這是方法呼叫參數，不是傳入 Update 的結構；也不是把任何文字放進回應主體，就會自動變成聊天訊息。

官方 FAQ清楚指出這項取捨：請求較少，但無法知道呼叫是否成功或取得結果。因此，伺服器日誌中的 HTTP 成功回應，不能補回缺少的發送結果。

本文假設機械人已能收到更新。如果仍在選擇身份和接收方式，請先閱讀 Telegram Bot API webhook 與統一入站 webhook 比較。選擇輪詢還是 webhook，與收到更新後如何回覆用戶，是兩項不同決策。

內嵌回覆與獨立 sendMessage 請求比較

判斷項目	在 webhook 回應中呼叫	獨立 Bot API 請求
呼叫形式	回應主體包含 method 和參數	應用程式另行呼叫方法
方法結果	無法取得	可檢查 Bot API 回傳的 JSON
已發送訊息識別碼	此機制不回傳	sendMessage 成功時回傳 Message
錯誤處理	沒有方法結果可作判斷	檢查回傳的 ok、description、error_code
適用情況	不依賴結果的簡單回覆	需要審計紀錄、背景處理或後續動作

官方回應格式與 sendMessage 定義說明，回應包含 ok；成功結果在 result，失敗時提供錯誤資料。sendMessage 成功時回傳已發送的 Message。

方法成功仍不代表收件人已讀。另外，即使另行呼叫 API，若遠端已處理請求但用戶端遺失回應，結果仍可能不確定。

**假設情境：**機械人只回覆一段說明，之後不需要引用訊息識別碼，可考慮內嵌回覆。若客服系統要把發送紀錄連結到工單，或根據 API 拒絕原因決定下一步，則應另行呼叫並保存實際結果。

分開記錄接收確認與發送結果

對於處理時間較長的流程，可採用以下應用程式設計；這並非 Telegram 額外提供的 API 保證：

1. 驗證 webhook 來源，將更新持久化儲存。
2. 確認接收，不等待 AI、CRM 或發送工作。
3. 由背景工作另行呼叫 Bot API。
4. 把真實結果或錯誤記錄到本地工作項目。
5. 將網絡逾時視為結果不確定，而非直接認定發送失敗。

以機械人身份為範圍去除重複更新。重複投遞應找到原有工作，不應建立另一份回覆。同時指定唯一的發送執行者：不要在 HTTP 回應內嵌入回覆後，又讓背景工作發送同一內容。

Telegram 文件說明，webhook 回傳非 2XY 狀態時會重試未成功的投遞。這是入站更新的投遞重試，不能代替追蹤出站方法結果。如果更新已收到但回覆未出現，應先檢查發送紀錄，而非直接改動 webhook 設定。getWebhookInfo 排查指南解釋了為何投遞狀態不能證明業務已完成。

UnifyPort 不會把回應主體當成發送指令

UnifyPort 的非官方接口不採用 Telegram 的回應內方法呼叫慣例。Webhook 投遞文件規定，任何 2xx 都確認投遞，回應主體會被讀取並捨棄。因此，回傳 method: sendMessage 不會透過這項規格執行發送。

對已連接的訊息帳戶，應接收 message.received、驗證簽章、儲存事件，再確認投遞。設定 signing_secret 後，X-Device-Signature 使用 HMAC-SHA256，簽署內容為 X-Device-Timestamp、一個點號和原始請求主體。

另行透過 POST /v1/messages 發送，並使用 X-Api-Key 認證。文字訊息參考文件定義了 account_id、to.id、to.type、message.type 和 message.text。回應範例中的 data.status: accepted 不應被當成已讀回條。自動回覆工作亦應檢查 data.message.direction，避免觀察到自己發出的訊息後再次觸發回覆。

需要機械人身份時，應繼續使用官方 Bot API。UnifyPort 的帳戶連接流程是另一種整合，不會找回內嵌 Bot API 呼叫的結果。它亦不提供 REST 訊息歷史讀取 API 或保證重播；需要的事件必須在到達時保存。

常見問題

可以直接回傳 sendMessage JSON，省去獨立 API 請求嗎？

Telegram Bot API webhook 可以，但必須符合官方方法回應格式，而且無法檢查呼叫是否成功或取得結果。

回傳 200 OK 代表回覆已發送嗎？

不是。它確認的是 webhook 投遞；出站方法結果是另一項結果。

獨立 API 請求逾時後應立即重發嗎？

不要盲目重發。遠端可能已發送，只是回應遺失。先保留不確定狀態，再按明確的核對或重試流程處理。

可以在 UnifyPort webhook 回應內放入聊天回覆嗎？

回應主體會被捨棄。請另行呼叫 POST /v1/messages。

下一步與來源

先判斷是否需要可觀察的發送結果，再選擇方式。連接訊息帳戶時，可由文字訊息 API 規格開始。

官方來源核對日期：2026-09-20。

• Telegram Bot API
• Telegram 回應格式與 sendMessage
• Telegram Bots FAQ