Telegram Webhook Has No Message Text? Check the Payload

If your Telegram forwarding webhook arrives but the message body is blank in your archive, check the payload settings on that exact endpoint before changing the forwarding task. RedFox Auto Forward Telegram’s Outbound Webhooks add-on separates event subscriptions from the data included in each notification. Its documented Include Message Text option includes forwarded text or captions; source and target information have separate options.

This guide is for an existing integration where the intended Telegram copy arrives and the receiver gets a notification, but a CRM or archive cannot display the words. It helps distinguish an omitted payload, an incorrect field mapping and text that was already absent in the delivered copy. It is not a new forwarding setup or a retry/deduplication implementation.

RedFox provides the product; Auto-Bot.io publishes this guide. The previous bot has moved to @AutoForwardNew_Bot, the current entry point for RedFox Auto Forward Telegram. Documentation was checked October 30, 2026. The examples are proposed checks, not an executed forwarding or webhook test. The featured illustration is a concept, not product UI.

1. Locate the first place the words disappear

Imagine a workshop team forwards its own notice to a private Telegram reading channel. A separate archive receives a notification for that delivery, yet shows an empty body. Compare the same harmless notice at three layers:

1. Delivered Telegram copy: open the actual target post. Does it contain the expected text or caption? Inspect the delivered version, not just the source.
2. Received webhook: have the integration maintainer inspect the authenticated request at the receiving endpoint, before a workflow maps it into fields. Does it contain the expected harmless wording anywhere in the documented message data?
3. Archive record: compare the receiver’s parsed value with the stored record and its display. Is the body missing from storage, or merely not shown?

Use a distinctive specimen such as Workshop check A: bring a notebook. Match it to the correct task, destination and request. A receiver log from a different endpoint is not evidence about this delivery. Keep raw private messages and signing secrets out of public request inspectors and support screenshots.

Follow the first confirmed gap. If the target copy already lacks its caption, payload inclusion cannot restore content that was not delivered. Use the separate photo/caption forwarding diagnostic. If the authenticated request contains the words but the archive does not, investigate the receiver mapping or storage—not the Telegram route.

2. Inspect the endpoint’s payload options

The official Outbound Webhooks guide documents up to three endpoints per task. Each endpoint can have its own events, signing secret, retry/timeout settings and payload configuration. Check the endpoint whose request you actually received, not another endpoint that happens to work.

• Include Message Text: includes forwarded message text or captions. This is the relevant data choice when the external archive needs the words.
• Include Source Information: includes source chat information. It serves attribution, not as a substitute for the message body.
• Include Target Information: includes destination chat information. It helps distinguish where a copy was delivered, not what it said.

For an archive that needs content, inspect whether Include Message Text is enabled and saved on the intended endpoint. For a monitoring receiver that needs only activity information, omitting text may be intentional. Define each destination’s data needs instead of enabling every payload option everywhere.

Confirm current add-on access on the account managing the task. The add-on overview describes credit-based, time-limited access; this guide does not promise a price, duration or plan inclusion. An existing working notification is a reason to inspect that configuration, not to purchase another endpoint or recreate the task.

3. Do not confuse event selection with body inclusion

The feature guide names three lifecycle events: new_message after a successful forward, edit_message after a successful target-message edit and delete_message after a successful deletion. Selecting an event answers which action should notify this endpoint? Payload options answer which information should accompany it?

Start this diagnosis with an ordinary new text post and new_message. Adding edit and delete subscriptions is not a substitute for checking Include Message Text. Conversely, enabling text does not subscribe an endpoint to later edits or activate edit/delete forwarding on the task.

Do not treat a notification as a copy of every raw source action or as evidence that a recipient read the message. The documented trigger is a successful task action. A Telegram copy, an HTTP notification and an archive update are separate results.

4. Verify the receiver mapping against RedFox’s contract

If the words are present in the authenticated request, ask the integration maintainer to follow that value through parsing, transformation, storage and display. An automation step may read the wrong location, overwrite a populated value with an empty one, or map a text-only field for a media-caption case.

A public TelegramBots question describes an adjacent problem: a developer found text in plain-message updates but could not find it in photo updates; a reply pointed to captions. That discussion concerns a Telegram bot webhook, not RedFox’s outbound integration. It is a useful reason to test text and caption cases separately, not a RedFox payload specification.

Telegram’s own Message reference distinguishes optional message text from optional media captions. Do not assume RedFox sends Telegram’s raw Update object or uses the same JSON paths. Its public add-on guide describes inclusion options but does not provide a complete receiver schema or signature-verification recipe. Obtain the current contract from RedFox support and compare it with a harmless authorized delivery before implementing a production parser.

Do not invent a field named message.text, a caption fallback path or a signature header for this integration. Keep a receiver without a confirmed authentication and parsing contract in isolated inspection-only staging, with business actions disabled. The missing public schema is an implementation prerequisite to resolve, not evidence that payload inclusion is unavailable.

5. Compare fresh text and caption specimens privately

The following is a reader-run acceptance procedure, not test results. Use an existing authorized private source and target plus a receiver you control. Keep external emails, CRM notifications and other real business actions disabled. If that isolation or the receiver contract is unavailable, stop at read-only inspection rather than experimenting on a live audience.

1. Preserve the baseline. Record the task, source, target, exact endpoint, selected events, saved payload switches and receiver mapping. Preserve relevant filters, sender rules and transformations. Account for pending work and other routes.
2. Observe the current setting. Send one fresh permitted plain-text specimen. Confirm its target copy, authenticated request and archive/display result. If the target did not receive it, this is not a valid payload-inclusion comparison.
3. Change one justified variable. If text inclusion was off and the archive is authorized to store it, enable only Include Message Text on the test endpoint. Save and reopen to verify the setting. Leave event selection, other endpoints and the forwarding route unchanged.
4. Use a fresh comparable post. Send a new allowed text specimen with a different harmless label. Compare the target copy, received body and archive result. Require a successful before/after explanation; do not infer it from a checkbox alone.
5. Check the media path separately. Use an owned photo with a harmless caption such as Workshop check C: room opens soon. Verify the caption in the target and then its documented receiver mapping. A captionless photo is a useful empty-content control, not evidence that caption inclusion failed.
6. Retain exclusions. Include a specimen rejected by an already verified task rule and confirm it remains excluded. If the rule’s match cannot be established, the exclusion check is inconclusive. Do not disable filters to obtain a convenient success.

If inclusion was already enabled and the raw request has the words, leave the switches alone and test only the justified receiver-mapping change with fresh comparable specimens. If the request still lacks words that are visible in the target, preserve sanitized settings and observations for support. Stop stacking configuration changes.

Before a live change, require the intended words to reach the correct archive record and verify that content is not newly exposed to an endpoint that should remain metadata-only. Restore an unexplained change. Changing a payload switch is not evidence that earlier notifications will be resent or old archive records repaired; reconcile those records separately instead of reposting to Telegram.

6. Keep each receiver’s data needs deliberate

An archive and an operations dashboard need not receive identical data. For example, an archive may require the delivered wording and a verified destination-message identity, while a monitoring receiver may need only the activity and identifiers necessary for its approved job. Source and target information can also reveal private chat details: minimize those fields as deliberately as text.

GitHub’s webhook best practices support narrow subscriptions, HTTPS and secrets outside endpoint URLs. Those are general design principles; GitHub’s header names, deadlines and redelivery controls are not RedFox’s protocol. RedFox documents a per-endpoint signing secret: have the maintainer verify it using RedFox’s current contract before trusting requests.

Turning off future text inclusion does not delete previously stored requests, logs, queue entries or backups. Apply your own authorized retention process to those copies. Do not call a metadata-only setting anonymous, a deletion guarantee or a compliance certification.

For repeated notifications creating duplicate rows, use the existing webhook retry and archive identity guide. This article’s body-inclusion checks do not replace durable event handling or prove exactly-once delivery.

FAQ

Why does a photo case fail when plain text works?

First confirm that the delivered photo has a caption. Then inspect the authenticated RedFox request and its documented mapping. Text-only parsing is a hypothesis to test, not permission to substitute Telegram Bot API field paths.

Should I enable text, source and target on every endpoint?

No blanket change is needed. Choose the data each authorized receiver needs. For this symptom, inspect message-text inclusion on the endpoint feeding the affected archive and preserve unrelated settings.

Will enabling text fill old blank archive rows?

The guide does not establish automatic historical repair. Verify fresh deliveries first, then reconcile any old gaps using an authorized process. Do not replay source posts to a real audience merely to generate archive data.

Inspect one endpoint before rebuilding the route

Open the Auto Forward Web App, or choose the official iOS app or Android app. Web/App is recommended for fuller management than the limited Telegram-bot entrypoint. Active tasks run in RedFox’s cloud without keeping the management interface open; the external receiver must still be available.

Your next useful result: identify whether the missing words originate in the delivered copy, the selected endpoint’s payload or the receiver mapping. Review the Auto Forward Telegram overview and the official payload options, then verify one private text-and-caption comparison before changing a live integration.