Introducing Agents.·Read
OverviewAgentsWorkflowsExecutionDeveloper ToolsSecurityLibrary
Updated Oct 19, 2026

Integrations

Plan Telegram message and file operations

telegram-integration is a selected-action workflow adapter for Telegram.

Agent
Preview message routingSupply a local media fileRetain operation results

overview

What telegram-integration does

Select message.sendMessage, message.sendPhoto or message.sendDocument and provide the intended chat and input fields. Explicit dry-run emits a plan without calling Telegram. Normal-mode media operations upload the supplied FILE using multipart requests.

Source-declared actions: message.sendMessage, message.sendPhoto, message.sendDocument.

A FILE of JSONL results, with an ok field per processed item. Dry-run rows include dry_run: true and planning fields, not a provider response or proof of execution. The registered contract also exposes a FOLDER output. Payload and text fields may contain supplied content; use synthetic data for shared examples.

Native executable tests cover all 3 declared actions using owned loopback HTTP fixtures, plus credential/error cases. No real provider calls were made. A private three-node platform workflow passed with downloaded dry-run plan and verifier outputs. This verifies planning and typed file flow, not provider HTTP or execution. Public image and source/notices directions are available. The original tool entry is available in the public Library. Keep private platform planning separate from provider execution.

source hub.docker.com/r/nenadzaric/skills-integrations-telegram-integration

use cases

Where telegram-integration fits

Preview message routing

Inspect a synthetic chat/text plan with dry-run true; this does not send or confirm delivery.

Supply a local media file

Normal sendPhoto/sendDocument reads the corresponding FILE port. Native multipart fixtures verify file payload handling; dry-run does not exercise upload.

Retain operation results

Normal results include the message identifier returned by the configured provider. Fixture identifiers demonstrate parser behavior, not a real delivered message.

reference

telegram-integration inputs and flags

13 inputs
NameTypeFlagDescription
itemsFILE--itemsOptional. One JSON object per line (JSONL); each line is one API call. If omitted, uses upstream files in /hive/in or a single send from flags. Example: {"text":"Finding ready","chat_id":"-100123"}
photoFILE--photoPhoto URL or path (sendPhoto; also accepted per JSONL item key "photo")
tokenSTRING--tokenBot token ; wire to ${{vars.TELEGRAM_BOT_TOKEN}} Supply via workflow secrets; never bake credentials into images, source, or shared inputs.
chat-idSTRING--chat-idChat/channel id ; wire to ${{vars.TELEGRAM_CHAT_ID}}
dry-runBOOLEAN--dry-runOptional: true returns a request/message plan without provider calls; omitted/false keeps normal configured execution. This is not a live provider test.
documentFILE--documentDocument URL or path (sendDocument; also accepted per JSONL item key "document")
resourceSTRING--resourceTelegram resource (default: message)
operationSTRING--operationOperation: sendMessage | sendPhoto | sendDocument

Showing key inputs. telegram-integration exposes 13 inputs in total.

Full flag reference (13 inputs)
NameTypeFlagDescription
textSTRING--textMessage text (single send; omit when reading items)
itemsFILE--itemsOptional. One JSON object per line (JSONL); each line is one API call. If omitted, uses upstream files in /hive/in or a single send from flags. Example: {"text":"Finding ready","chat_id":"-100123"}
photoFILE--photoPhoto URL or path (sendPhoto; also accepted per JSONL item key "photo")
tokenSTRING--tokenBot token ; wire to ${{vars.TELEGRAM_BOT_TOKEN}} Supply via workflow secrets; never bake credentials into images, source, or shared inputs.
captionSTRING--captionCaption for sendPhoto / sendDocument
chat-idSTRING--chat-idChat/channel id ; wire to ${{vars.TELEGRAM_CHAT_ID}}
dry-runBOOLEAN--dry-runOptional: true returns a request/message plan without provider calls; omitted/false keeps normal configured execution. This is not a live provider test.
documentFILE--documentDocument URL or path (sendDocument; also accepted per JSONL item key "document")
resourceSTRING--resourceTelegram resource (default: message)
operationSTRING--operationOperation: sendMessage | sendPhoto | sendDocument
parse-modeSTRING--parse-modeTelegram parse mode: Markdown | MarkdownV2 | HTML
text-fieldSTRING--text-fieldWhich item field holds the message text (default: text)
continue-on-errorBOOLEAN--continue-on-errorKeep going (and exit 0) when an individual send fails

example

Run telegram-integration

telegram-integration · command
telegram-integration --dry-run --resource message --operation sendMessage --chat-id -12345 --text "D074 owned plan fixture" --output ./plan.jsonl
sample output
{"resource": "message", "operation": "sendMessage", "chat_id": "-12345", "ok": true, "dry_run": true, "method": "sendMessage", "text": "D074 owned plan fixture"}

guidance

Choosing telegram-integration

Use this service-specific adapter when the selected provider action and typed fields match the workflow. Dry-run planning, native HTTP-mock acceptance and actual provider execution are separate capabilities. A generic HTTP client may suit API routes this adapter does not expose.

faq

telegram-integration questions

message.sendMessage, message.sendPhoto, message.sendDocument. This describes the recovered adapter, not every API capability offered by the provider.

The actual image returns a JSONL request or message plan without a provider call. This covers argument and planning/output behavior. It does not validate production account permissions, send a message, upload media or confirm provider compatibility.

Use the credential inputs for the selected service and operation, bound through the existing workflow secret mechanism. Do not put credentials into shared input files, examples or source. Explicit dry-run true generates a plan without provider calls; omitted/false selects normal configured execution. Missing and invalid credential behavior was exercised against synthetic local fixtures, not a production account.

A FILE of JSONL results, with an ok field per processed item. Dry-run rows include dry_run: true and planning fields, not a provider response or proof of execution. The registered contract also exposes a FOLDER output. Payload and text fields may contain supplied content; use synthetic data for shared examples.

Native executable tests cover all 3 declared actions using owned loopback HTTP fixtures, plus credential/error cases. No real provider calls were made. A private three-node platform workflow passed with downloaded dry-run plan and verifier outputs. This verifies planning and typed file flow, not provider HTTP or execution. Public image and source/notices directions are available. The original tool entry is available in the public Library. Keep private platform planning separate from provider execution.

Open the source link for immutable image and source-notices download commands, the bundle SHA-256, recovered adapter/build files and installed notices. Provider HTTP-mock tests and private platform dry-run planning are separate from live provider compatibility or delivery.

related

More Integrations tools

  1. github-integration

    Select a GitHub resource and operation, supply its repository fields, and retain a JSONL result. The explicit dry-run input generates a request plan without calling GitHub. Normal execution uses a token and can create or change repository data.

  2. jira-integration

    Select an issue operation and supply its site and issue fields. Dry-run generates a method, URL and payload plan; it does not create a Jira issue or establish that an account has the required access.

  3. notion-integration

    Supply the selected resource, operation and page/database fields. Dry-run returns a planned API request without calling Notion. Normal execution may read, create, update or archive data depending on the operation.

  4. slack-integration

    Choose the Slack resource and operation, then supply message or lookup fields. Dry-run reports a message plan without contacting Slack. It does not verify a webhook, workspace membership, delivery or media content.

Run telegram-integration yourself

Complete retained JSONL plan from the current notices1 image using synthetic owned fixture data. This was dry-run planning, not a provider request or delivered message. Native HTTP-mock action coverage is recorded separately.

Open telegram-integration in the libraryBuild a workflow with it

Facts on this page come from the live Trickest tool library.