Telegram in 2026: Still a Data Source, Now a Real Agent Platform

The job came in as a Slack message. “We need a list of who’s in our partner’s Telegram channel. They said we have permission. Can you pull it by Friday?”

The data engineer opened the docs. Bot API: no method to list channel members. Stack Overflow: a 2019 tutorial using a library called Telethon and a flag called aggressive=True. They ran the code. It crashed with aggressive is no longer supported. They tried the next snippet. It returned 200 users with all phones as None. The channel had 14,000 subscribers.

This is the first thing to know about Telegram as a data source in 2026: the methods still exist, they still work, but almost everything written about them on the open internet is at least two API generations out of date. This article is the current version, plus a frame shift most teams have not made yet: Telegram is no longer just a data source.

What still works, and what does not

The Bot API, the official high-level interface, still does not expose channel members. Bot API 10.0 shipped in May 2026 with Live Photos and Guest Mode, and there is still no getChannelParticipants method. There is no public timeline for adding one. If your plan starts with “the bot will pull the subscriber list”, the plan is wrong.

The MTProto path (the lower-level interface used by the Telegram client itself) still works, and Telethon is still the standard Python wrapper. What changed since 2021:

• The aggressive=True parameter on get_participants is gone. The method now pages through ChannelParticipantsSearch queries internally, and you have to handle the paging if you want all subscribers from a large channel.
• The phone field on every member object is almost always None. Telegram tightened the privacy default in 2023, then again in 2025, so a phone is only visible to mutual contacts or admins of channels the user explicitly trusts.
• The username field is increasingly None as well. With the rise of t.me/+random_invite_link joins and username NFTs on Fragment, plenty of users now have no username at all.
• Rate limits are stricter. A naive loop over a 50k-member channel will trigger FloodWaitError within a few minutes; you need exponential backoff and session reuse.

The methods that still produce useful data:

• iter_messages(channel, limit=N) on any public channel returns the full message history, including reactions, reply counts, view counts, and edit timestamps. This is the highest-signal pull you can do today.
• get_participants(my_own_channel) on a channel where you are admin returns the full member list with whatever profile fields each member chose to expose. For your own channels this is genuinely useful for analytics.
• iter_participants(group, filter=ChannelParticipantsSearch('keyword')) lets you search members of a group by display-name keyword. Useful for moderation, not for scraping.

The ethics line, drawn sharper than in 2021

The 2021 version of this article ended with the code and walked away. In 2026 that is irresponsible, because two things changed in parallel: the data Telegram exposes is thinner, and the enforcement around what you do with what you pull is tighter.

The practical rule: pull only your own assets. Subscribers of channels where you are admin, messages from public channels you would naturally read, profile metadata from users who chose to expose it. Anything else, including the partner-channel pull from the opening scene, requires written permission from the channel admin and a clear lawful basis under whatever jurisdiction your business operates in (GDPR for EU, CCPA for California, similar regimes elsewhere).

What gets you banned (not necessarily sued, but banned, which for a data team is the same problem): scraping public channels at industrial volume, joining channels purely to dump members, reselling phone numbers or usernames, building a “Telegram data product” that resells access to other people’s audiences. Telegram’s anti-spam team flags the access patterns, not just the content, and once a phone-number-account is flagged it is essentially unrecoverable.

The honest answer to “can we pull this partner channel’s subscribers” in 2026 is usually “ask the admin to add you as an admin for an hour”. That is the only path that is both compliant and produces usable data.

What Telegram became while no one was looking

Between November 2024 and May 2026, the Bot API went from version 7.6 to 10.0. That is sixteen point releases in eighteen months. The cumulative shape of the platform is unrecognizable from the 2021 picture.

The releases that matter for builders, in rough order of “you should know this exists”:

Mini Apps. Full HTML/JS apps that render inside a Telegram chat, with persistent storage, geolocation, device motion sensors, fullscreen mode, and a homescreen-shortcut install path that bypasses the iOS App Store and Google Play. If you are building a small consumer tool and your audience already lives in Telegram, you can ship a real product without ever touching Xcode or the Play Console.

Stars payments. Telegram’s internal currency, redeemable for real money on the platform side. Bot API 8.0 (November 2024) added Star Subscriptions; Bot API 7.x added paid media, paid reactions, paid broadcast messages. For micro-billing inside a chat (one-shot purchases, monthly subscriptions, tipping), Stars sidesteps the Stripe integration, the EU VAT MOSS dance, and the App Store’s 30% cut.

Business API. Bot API 9.0 (April 2025) added a full surface for managing business accounts: post stories, manage profile, send gifts, set bios. If you are running a customer-service bot inside a business account, you can now do it through Bot API instead of a human operator.

Guest Mode. Bot API 10.0 (May 2026) lets bots receive messages and reply in chats where they are not members. This is genuinely new. Before May 2026 a bot had to be invited; now any user in any chat can @your_bot some_query and your bot can respond. The implication for agent UX is large: one bot can serve unlimited chats without an invite step.

Managed Bots. Bot API 9.6 (April 2026) added the ability to create and manage bots from another bot. The first time you do this you feel mildly unsafe, then you realize it lets a parent agent spawn specialized sub-agents on demand, each with its own token and rate-limit budget.

Custom emoji, topics in private chats, checklists, suggested posts. Each of these is small on its own and collectively shifts the surface area enough that a 2021 Telegram bot looks primitive next to a 2026 one.

The original framing of “Telegram as a data source” treated the platform as a passive corpus you scrape. The 2026 framing has to treat it as an active platform you build on, because the build path improved by 10x while the scrape path got marginally worse.

Telegram as an agent platform

The interesting question for a data team in 2026 is not “how do I pull data from Telegram” but “should my next agent live inside Telegram instead of a web app?”

The case for Telegram as agent UI, on the merits:

• The mobile UX is already built. Your agent ships the moment your bot token is provisioned. No App Store review, no React Native, no push-notification setup, no auth flow.
• The desktop client is a real client. Keyboard shortcuts work. Long messages render. Code blocks have copy buttons. For an agent that returns long-form output, Telegram’s render quality beats Slack’s by a noticeable margin and matches Discord at default.
• Webhooks work without TLS gymnastics. Telegram’s setWebhook accepts a self-signed cert if you upload the public key, and any reverse proxy with Let’s Encrypt is fine. A small VPS can host an agent with no observable latency.
• Rate limits are generous at small scale. A 30-message-per-second burst limit per chat is plenty for any conversational agent that does not stream tokens. (For streaming, the limit becomes the LLM provider’s, not Telegram’s.)
• Mini Apps fill the gap when chat is the wrong UI. If your agent occasionally needs to show a table, a chart, or a multi-step form, you ship a Mini App for that one screen and the rest stays in chat.
• Stars handle billing inside the chat. For a paid agent, the customer pays in the same UI they use the agent, no redirect to a payment page, no Stripe Elements, no MOSS filings.

The case against, on the merits:

• Telegram is a consumer messenger. If your buyers expect Slack or Microsoft Teams (most B2B), the agent has to live there instead.
• Mini Apps are not full mobile apps. Background tasks, push notifications, deep OS integration: not available. The agent has to be reachable, not resident.
• The Bot API has soft rate limits that hit at production scale. Above a few thousand active users you start needing per-bot horizontal sharding, which is more ops than a single VPS gets you to.

For the bands of “personal agents you build for yourself” and “consumer-facing agents whose users already live in Telegram” (the largest segment globally outside North America), Telegram is the right platform. For internal-tool agents inside a North American B2B company, it is not, and Slack still wins.

Case study: a personal assistant bot, and a router behind it

The clearest way to show what 2026 Telegram-as-agent-platform looks like is to walk through one bot.

A personal assistant bot, the one I run for myself, lives in a single chat with one user (me) and exposes a small command surface:

• /morning summarizes overnight email, the day’s calendar, and the top open tasks
• /digest produces a weekly review (project status, time spent, follow-ups due)
• /upwork status pulls active client work from Upwork’s API and flags anything pending response
• /calendar lists today’s meetings with one-line briefings pulled from Notion
• /things adds or completes tasks in Things 3 via its local AppleScript bridge

The architecture, end to end:

1. The Telegram bot runs as a tiny Python service on a VPS, registered with setWebhook against the VPS public URL.
2. Each incoming message hits an asyncio dispatcher that maps commands to handlers.
3. A handler that needs external data (Notion, Things, Upwork, Gmail) calls the appropriate MCP server. MCP (Model Context Protocol) is the open standard Anthropic shipped in late 2024; each MCP server is a tiny process that exposes a single integration’s read/write surface to any LLM client. The Notion MCP, Things MCP, Gmail MCP, and so on each expose ten to thirty tools.
4. The handler sends the user’s message plus the MCP tool results to an LLM. The LLM picks the tools to call, calls them, and returns a Telegram-formatted reply.
5. The bot posts the reply, optionally with a Telegram inline keyboard for follow-up actions (“mark this task done”, “snooze for 1 day”).

That is the entire stack. Total LOC for the bot itself is under 400 lines of Python. Everything else lives in MCP servers (which you write once per integration, then reuse from any LLM client) and the LLM provider.

The interesting question is what happens when one personal assistant is not enough. You add a second bot, then a third, then you realize each one has its own token, its own command surface, its own VPS process. Operationally you have invented a tiny fleet.

OpenClaw is the layer that collapses the fleet back into one routable surface. It runs as a single container on the same VPS (ghcr.io/hostinger/hvps-openclaw:latest in the public build) and accepts incoming messages from Telegram, WhatsApp, and Discord through a unified channel layer. Internally it routes each message to one of several LLM providers (Claude, GPT, Kimi, Gemini) based on a configurable rule set, runs MCP tools the same way the personal assistant does, and replies through whichever channel the message came in on.

The two patterns interact. The personal assistant bot is the “user-facing” face of the agent; OpenClaw is the “model-and-tools” engine behind it. The bot logic stays thin and stable (command parsing, response formatting); the routing, provider selection, and tool calling stay in OpenClaw, where they can be reconfigured without touching the bot deployment.

The pragmatic checklist for building on Telegram in 2026

For each of the three plausible jobs:

If you need to extract data from existing Telegram surfaces, use Telethon, target your own channels, expect thinner profile data than in 2021, page through results, handle FloodWaitError, and have a written admin permission stored somewhere auditable for any pull that touches another organization’s audience.

If you need to ship a small consumer tool to people who already use Telegram, build a bot with python-telegram-bot or aiogram (Python) or Telegraf (Node), add a Mini App for any screen that does not fit in a chat message, use Stars for billing, deploy to any VPS with a reverse proxy. Total stack cost under $20/month for the first thousand users.

If you need a personal agent that follows you across devices, you do not need Slack, Discord, or a custom app. A Telegram bot with three or four MCP server integrations and a single LLM provider hits 95% of what you want, in under 500 lines of Python, in one weekend.

The remaining 5% (background tasks, OS-level integrations, true offline support) is where you reach for native code. For everything else, Telegram is the path of least resistance for a builder in 2026.

The 50-line example, updated

Below is the 2026 version of the code from the original article: pull subscribers from a channel you own, with all the 2026 caveats handled. Runs on Telethon 1.36 or newer, Python 3.10 or newer.

import asyncio
import os
import pandas as pd
from telethon import TelegramClient
from telethon.errors import FloodWaitError
from telethon.tl.types import ChannelParticipantsSearch

API_ID = int(os.environ["TG_API_ID"])      # https://my.telegram.org → API development tools
API_HASH = os.environ["TG_API_HASH"]
SESSION = "subscribers"                     # any unique name; persists in ./subscribers.session
CHANNEL = os.environ["TG_CHANNEL"]          # e.g. "@your_own_channel" or invite link

async def fetch_all_participants(client, channel, page_size=200):
    offset = 0
    out = []
    while True:
        try:
            chunk = await client.get_participants(
                channel,
                limit=page_size,
                offset=offset,
                search="",                  # empty = all
            )
        except FloodWaitError as e:
            print(f"flood wait: sleeping {e.seconds}s")
            await asyncio.sleep(e.seconds + 5)
            continue
        if not chunk:
            break
        out.extend(chunk)
        offset += len(chunk)
        if len(chunk) < page_size:
            break
        await asyncio.sleep(0.3)            # polite throttle
    return out

async def main():
    client = TelegramClient(SESSION, API_ID, API_HASH)
    await client.start()
    members = await fetch_all_participants(client, CHANNEL)

    rows = []
    for m in members:
        rows.append({
            "id":         m.id,
            "username":   m.username,        # often None in 2026
            "first_name": m.first_name,
            "last_name":  m.last_name,
            "phone":      m.phone,           # almost always None
            "is_bot":     bool(m.bot),
            "is_premium": bool(getattr(m, "premium", False)),
        })

    df = pd.DataFrame(rows)
    df.to_csv("subscribers.csv", index=False)
    print(f"wrote {len(df)} rows; "
          f"{df['username'].notna().sum()} with username, "
          f"{df['phone'].notna().sum()} with phone")

    await client.disconnect()

asyncio.run(main())

Three things to notice, mapped to the three 2026 changes:

The aggressive flag is gone; we page manually with offset and page_size. The FloodWaitError branch is mandatory for any channel above a few hundred members. The print at the end honestly reports how many usernames and phones you actually got, which on any real 2026 channel will be a small minority of the total members. Plan around that number, not around the row count.

If you are running this against any channel where you are not the admin, stop and reread the ethics section.

What to do this week

If your team has a Telegram extraction job sitting in a notebook, take ten minutes:

• Update the Telethon call to remove aggressive=True (the script is silently failing if it is still there).
• Add a FloodWaitError handler and a paging loop.
• Add a print at the end that reports how many usernames and phones came back, as a fraction of total members. If that fraction is below 30%, your downstream analysis is built on thin data and needs a rethink.
• Audit which channels you are pulling from. For anything that is not your own asset, archive the job and replace it with a written admin-permission request.

And if your team has been thinking about an internal agent and was about to start a Next.js app for it, take a different ten minutes: register a Telegram bot, point its webhook at a 50-line Python handler, and see if you actually need the web app. For internal tools and personal agents in 2026, you usually do not.

About the author

Nick Valiotti is the founder of Valiotti Data. 15+ years building analytics infrastructure for SaaS, marketplaces, and consumer subscription. 50+ production deployments across BigQuery, Snowflake, dbt, Metabase, and modern BI stacks. Author of two books on data strategy. LinkedIn · Discovery call.