Plan Telegram user-account messaging as a stateful session

The target Telegram connector covers user-owned chats, groups, messages, attendees, files, and account events through Telegram's account API path. It remains planned and has no released session runtime.

Illustrative product surface. The workflows below are planned, not a live connector.

Talk to us ↗Read technical guides →

Capability boundary

Telegram user sessions are planned, not live

The catalog selects an official account API path but still requires Telegram application credentials, encrypted session custody, real-account conformance, and flood-wait enforcement.

Catalog status and access: Telegram user accounts — planned, official account api
Authentication: A user-account connection requires Telegram application credentials, an interactive authorization flow, and an encrypted long-lived session bound to the correct workspace and user. Bot authorization is a different product surface.
Resources: chats, messages, attendees, attachments
Target actions: chat.list, chat.get, chat.create, message.list, message.get, message.send, message.edit, message.delete
Target events: message.received, message.sent, message.edited, message.deleted, message.reaction
Limitations and failures: No Telegram session runtime is released; Flood waits and session invalidation require provider-specific handling; Bot-only behavior is not implied by the user-account catalog
Release gates: Telegram user accounts — Telegram application credentials, encrypted sessions, and flood-wait enforcement

Account type

Keep user sessions separate from bots

A user's existing conversations, a bot's update stream, and a public channel are different authorization and identity models. This route concerns a user-owned account session; bot features need a separate catalog and release decision.

Session custody

Treat the Telegram session as sensitive authorization material

The connector must bind session state to one tenant, restrict decryption to the provider worker, redact logs, and replace credentials atomically after reauthorization. A cached phone number is not proof that the session is healthy.

Chats and groups

Retain native participant and conversation context

The shared chat model can cover direct and group conversations while preserving Telegram identifiers, attendee roles, reply references, and file metadata. Provider-specific chat types should remain visible to callers that need them.

Updates

Commit message state before advancing the session checkpoint

A future worker should apply inbound, edited, deleted, and reaction updates idempotently, then advance its provider position only after the local transaction succeeds. Gaps require reconciliation rather than guessed continuity.

Rate behavior

Honor flood waits instead of retrying on a generic schedule

Telegram can return provider-specific wait instructions and authorization errors. The account should enter a visible delayed or reconnect state, and writes must not be replayed until their previous outcome is known.

Illustrative contract

Preview the intended integration boundary.

This shape documents the intended account and resource boundary. It is not callable, and it does not generate provider traffic.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapePlanned · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No live connector · no provider request

Questions

Before you build.

Is this the Telegram Bot API?+

No. The current target is a user-account connector; bot access would require a separate capability definition.

Can a Telegram account be connected today?+

No. The connector is planned and still lacks session custody and real-account conformance evidence.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗