Telegram Webhook Reply: Response Body vs Separate sendMessage Request

Telegram lets you invoke a Bot API method such as sendMessage inside the HTTP response to a webhook. However, Telegram explicitly says you cannot know whether that embedded request succeeded or obtain its result. Use a separate Bot API request when you need the returned message or an actionable error. Returning 200 OK to acknowledge an update is not the same as confirming a chat reply was sent.

Key takeaways

• An HTTP acknowledgement, a Bot API method result, and a message read by a person are different outcomes.
• An inline webhook response saves a separate request but gives up the method result.
• A separate sendMessage call is the better fit when later work depends on a message identifier or a recorded sending outcome.
• UnifyPort has a different contract: it discards the webhook response body. Sending requires a separate API call.

What a Telegram webhook response can do

The Telegram Bot API reference documents a special response mechanism: return method parameters using application/json, application/x-www-form-urlencoded, or multipart/form-data, and identify the Bot API method with method.

For example, an application can return method: sendMessage with the appropriate chat_id and text in a JSON response. This describes a Bot API invocation, not the JSON shape of the incoming Update. It also does not mean arbitrary text in a response body becomes a chat message.

Telegram’s official FAQ states the trade-off directly: fewer requests, but no way to know whether that request succeeded or obtain its result. Your server logging a successful HTTP response therefore cannot supply the missing outbound result.

This article assumes you already receive bot updates. For the earlier identity and transport decision, use Telegram Bot API webhook vs unified inbound webhook. Choosing polling versus webhooks is a separate question from deciding how to send a response to the user.

Inline reply vs a separate sendMessage request

Decision	Method inside webhook response	Separate Bot API request
Request shape	Response body contains method and method parameters	Your application calls the chosen API method separately
Method result	Not available to your application	Inspect the returned Bot API JSON
Sent message identifier	Not returned through this mechanism	Successful sendMessage returns a Message
Error handling	No method result to branch on	Inspect ok, description, and error_code when returned
Best fit	A simple reply whose result is not needed	Auditable sends, worker-based processing, dependent actions

The official response and sendMessage definitions say Bot API responses contain ok; successful results are in result, while unsuccessful requests include error information. sendMessage returns the sent Message on success.

A successful method result is still not proof that a person read the reply. Equally, making a separate call does not eliminate uncertainty if your client loses the response after the remote service processes the request.

Hypothetical decision: a bot produces a short informational response, and no later action depends on its identifier. An inline response may be sufficient. If your application must associate an outbound message with a support task or decide what to do after an API rejection, choose a separate call and preserve the actual result.

Keep acknowledgements and sending outcomes separate

For workflows with slow processing, the following is a recommended application design—not an additional Telegram API guarantee:

1. Authenticate the incoming webhook and durably store the update.
2. Acknowledge that intake without waiting for an AI model, CRM, or outbound send.
3. Let a worker make the separate Bot API call.
4. Store the returned result or error against the local task.
5. Treat a network timeout as an uncertain outcome, not automatic proof of failure.

Deduplicate incoming updates within the bot’s scope. A repeated delivery should locate existing work, not create another independent reply. Also choose one sending owner: do not both embed a reply in the webhook response and enqueue the same reply for a worker.

Telegram documents retries for unsuccessful webhook deliveries with a status outside 2XY. Those are retries of the incoming update delivery, not a substitute for tracking your outbound method result. If updates arrive but replies do not, inspect sending records rather than changing the webhook configuration. The getWebhookInfo diagnostics guide explains why delivery status alone does not establish business completion.

The UnifyPort response body does not send a message

UnifyPort’s unofficial interface does not implement Telegram’s embedded-method response convention. Its webhook delivery reference specifies that any 2xx acknowledges delivery and that the response body is read and discarded. Returning JSON containing method: sendMessage will not invoke that method through this contract.

For a connected messaging account, receive message.received, verify the delivery, store the event, and acknowledge it. With signing_secret configured, verification uses X-Device-Signature: HMAC-SHA256 over X-Device-Timestamp, a dot, and the raw request body.

Send separately through POST /v1/messages, authenticated with X-Api-Key. The text-message reference defines account_id, to.id, to.type, message.type, and message.text. Its example response includes data.status: accepted; do not relabel that as a read receipt. When building an auto-response worker, check data.message.direction so an observed outbound message does not trigger a reply loop.

Keep the official Bot API when the required identity is a bot. UnifyPort’s connected-account flow is a different integration, not a way to recover an unavailable inline Bot API result. It also offers no REST message-history read API or guaranteed replay; store required events on arrival.

FAQ

Can I return sendMessage JSON instead of calling the API?

Yes, for a Telegram Bot API webhook, using the documented method-response format. You cannot inspect that embedded call’s success or result.

Does returning 200 OK mean my reply was sent?

No. It acknowledges the webhook delivery. An outbound method result is a separate outcome.

Should I automatically resend after a separate API call times out?

Not blindly. The remote send may have completed before the response was lost. Preserve the uncertain outcome and apply an explicit reconciliation or retry decision.

Can a UnifyPort webhook response contain a chat reply?

The body is discarded. Use a separate POST /v1/messages request instead.

Next step and sources

Choose the sending path based on whether you need an observable result. For a connected-account implementation, begin with the text-message API contract.

Official references checked on 2026-09-20:

• Telegram Bot API
• Telegram response format and sendMessage
• Telegram Bots FAQ