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 拒絕原因決定下一步，就應另外呼叫並保留實際結果。

將接收確認與發送結果分開

需要較長處理時間的工作流程，可採用以下應用程式設計；這不是 Telegram 額外提供的保證：

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 是對 X-Device-Timestamp、一個句點與原始請求本文計算的 HMAC-SHA256。

另外透過 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