Stack Overflow holds 1 297 questions tagged telethon. Take the hundred most upvoted of them, sort those by views, and the top two say everything about how this usually goes: an asyncio error with 108 603 views, then a question titled «Telegram get chat messages / posts» with 98 166. Read on 18 September 2026 through the Stack Exchange API.
The second one is the actual goal. The first one is what the goal costs when you pursue it by logging a client in as yourself.
There are three ways to read a public channel from code, and the difference between them is less technical than it looks. It is what each one asks you to own.
| Path | What it reads | What you own |
|---|---|---|
| Bot API | chats the bot was added to, going forward | nothing |
| MTProto as yourself | everything your account can see, history included | a phone number, a session file, the timers |
| HTTP API in front of MTProto | public channels, posts, comments, recommendations | a plan |
1. The Bot API: free, official, and not for this
A bot receives updates from chats it has been added to, and it receives them going forward. No method takes a username you do not control and hands back the last two hundred posts: the Bot API page for version 10.3 contains no getChatHistory and no getHistory at all, read on 18 September 2026. On the same page getUpdates appears seven times, so that zero is a measurement rather than a search that quietly failed.
This is a permission boundary, not a gap someone forgot to fill, and no amount of engineering turns it into the right tool. If you own the channel, this path is free and correct. If you do not, it ends here.
2. MTProto with your own account
Telethon, Pyrogram and GramJS all speak the protocol the Telegram apps speak. You log in as a user, and from then on Telegram sees your program as you, with read access to everything you can see in the app.
Three things arrive with that, whether or not you wanted them.
A phone number tied to the project. The API id and hash come from my.telegram.org, and they come attached to a number that is now part of your infrastructure.
A session file worth stealing. It is not a cache. It is your account, sitting on disk.
Timers. GitHub code search finds FloodWaitError in 10 720 files (18 September 2026; the counter is approximate and moves between runs). That number is the size of the ecosystem built around waiting properly, and what the timer actually means is a post of its own.
There is also a question no library answers for you: whether an automated user account is something you want at all. The Stack Overflow thread that asks it directly has 4 381 views and has been open since November 2022, read on 18 September 2026.
If your program needs to act, joining channels, posting, reacting, then this is the path and it deserves to be taken seriously: pin a maintained client, wait out every timer, keep exactly one account, and never spread load across extra accounts to dodge a limit.
3. An HTTP API in front of MTProto
Somebody else keeps the session, the retry logic and the rate budget, and your side of it is a request with a key. What comes back is public data: channel metadata, posts with view and forward counts, the discussion thread under a post, the channels Telegram itself recommends alongside. Private chats and closed channels stay out of scope, which is exactly why this path needs no phone number and leaves you no account to lose.
Ours is tgAtlas. The free plan carries 2,500 requests and 50 lookups a month, enough to find out whether your project ever needed an account. The first call is a key and one curl.
The question that decides it
Does your program need to act as a Telegram user, or only to read what any visitor reads without logging in?
If it only reads, path 2 hands you a phone number, a session file and a rate limiter in exchange for powers your code never calls. That is the trade worth reconsidering, whichever provider you end up using.
First published on tgatlas.org.
Top comments (0)