All nodes/Integrations/Telegram
Telegram Get File
Downloads a Telegram attachment by file_id and stores it as a file reference (PT_FILE) that can be fed to an LLM/vision node or back into Send Telegram Message. The file_id comes from the recorded history ({{ nodes.telegram_history_1.rows[0].media_file_id }}). The Bot API serves files up to 20 MB only. Requires a Telegram Config.
Type in the graph: telegram_get_file
Exec
An error branch can be enabled (expose_error_output) to handle failures on their own path.
Try it
Minimal working workflow
- Execute
- Execute + Data
Runs as pasted
When to use it
Use this node when you hold a file_id from the recorded group history and need the bytes
themselves: download a photo to show a model, save a document with
File Write, or send it back into a chat.
For an attachment of the current turn the node is unnecessary: a file the user sent to the bot already arrives with the message at the workflow’s entry and reaches the LLM on its own. This node is about files that were not part of this turn.
How it works
Group-history recording deliberately stores attachments as references rather than bytes:
downloading every photo in a busy chat means gigabytes of files nobody will ever open. This
node is the lazy other half — it takes a file_id, downloads the content once and puts it
into the workspace file store, handing on a file reference rather than base64.
Take the file_id from the Records port of
Group History — for example
{{ nodes.telegram_history_1.rows[0].media_file_id }}.
Common mistakes
- A 20 MB ceiling. The Bot API serves bots files up to 20 MB only (and the workspace upload limit applies when it is lower). Anything larger is unreachable for a bot.
- A
file_idbelongs to one bot. An id recorded by one bot cannot be downloaded by another, so wiring in a different Telegram Config is not a workaround here — it is a cause of refusal. - The history’s Messages output carries no
file_id— only Records does. That is the most common reason the field ends up blank. - A blank
file_idis an error, not a skipped step. A template that rendered to an empty string stops the node, by design: otherwise the next vision node would receive “no attachment” and answer confidently about nothing. - The filename is not the original one. The Bot API does not return it, so the name comes from Telegram’s own storage path and the type is guessed from the extension.
- A file reference, not a path on disk. Wire the output into an LLM node, into Send Telegram Message or into Exit — they resolve such references themselves.
Inputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Telegram Configtelegram_config | Datadata | — | shown when connection_source ≠ "auto" |
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Fileoutput | Execute + Dataexecute_data | file | |
Erroron_error | Execute + Dataexecute_data | — | shown when expose_error_output = true |
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
Connection sourceconnection_source | string | auto | Where this node gets its connection. 'From the run context' uses what the platform already knows (the Telegram bot this workflow is deployed to / this workspace's own file store) and needs no wiring. 'External connection' shows the resource port so a config node can be wired into it. Options: |
File IDfile_id | string | "" | Telegram file_id of an attachment — typically from the history node: {{ nodes.telegram_history_1.rows[0].media_file_id }} (the Records port; the Messages output is for LLMs and carries no file_id). The Bot API serves files up to 20 MB. supports templates |
Shared fields
Every node has these three — the platform adds them, not the node author.
expose_error_output— When enabled, show an execution output to connect nodes that run if this step fails.