Does the installer ask for a bot token or a phone number?
That one question sorts the category, and almost nothing else does. Reach, scheduling, who carries the consequence when a run goes wrong, what a stolen copy is even worth to whoever took it: all of it falls out of the answer. Ask it first.
A bot token means the Bot API. One bot, one token, a documented HTTP surface, and a boundary written into Telegram's own introduction for developers: bots can't start conversations with users, and a person has to add the bot to a group or write to it first. None of that is a setting, a rate limit, or something a paid tier lifts, and there is no method to call.
A phone number means the other half. The tool signs in as a person over MTProto, holds a session file for that number, and can do roughly what the account holder could do by hand: write to a stranger, join a group, read a member list, post into a channel it owns. Nothing grants it permission, because it is not a third party asking. It is the account.
Both halves are sold on the same listings pages, under the same headline, with feature grids that look nearly identical. Member adder, scraper, bulk sender, auto-poster, analytics. Read down those grids and you cannot tell which machine you are looking at, which is exactly why the question above has to be asked out loud before money moves. We ask it of every tool somebody sends us to look at, and it answers more than the rest of the specification sheet combined. The vendors who answer it in one line, without being pushed, tend to be the ones worth a second conversation.
Say one practical consequence out loud now, because it changes what the rest of this is about. A bot token is disposable: revoke it, issue another, and the worst case is an afternoon of reconnecting things. A session is a live credential for a real phone number with a real history behind it, and there is no reissue button.
Which is also why the two halves attract different buyers entirely. If the job is answering people who already found you — a support bot, a subscribe flow, a channel that posts whatever your own system tells it to — the token side is both the correct answer and the cheaper one, and we will say so. If the job begins with a list of people who have never heard of you, no bot exists that can carry it, and that sentence is the one most listings pages leave out.
One phrase, a dozen shopfronts
The same category is sold as telegram marketing tools, as a telegram marketing software download on a page with no version number, as a telegram marketing software free download two clicks further along, and as telegram marketing software india on a listings site quoting a monthly figure an order of magnitude below anything aimed at the US market — and the pitch under every one of them is the same three moves: paste a list, paste a message, walk away.
The thing that actually differs between those shopfronts is never the pitch. It is the answer to the first question, and not one of those pages prints it.
The omission has a reason behind it beyond laziness. A directory earns across the whole category, so its incentive is to keep the category looking like one product with a lot of brands inside it, and splitting the table in two would halve the list. A listing that said plainly which half a tool belongs to, and what it is genuinely good at as a result, would be more useful than every comparison chart in the category. We have not found one yet.
Why is a telegram post scheduler only half a product?
Because the queue has to sit somewhere, and only one of the two machines can hand it to Telegram.
Start with what the app already does. Telegram's own clients have scheduled messages built in — hold the send button in a chat and pick Schedule Message, announced back when reminders and themes shipped, and it works in Saved Messages too, which turns a planned post into a reminder. The queue lives on Telegram's servers. Your laptop can be shut.
Underneath the client, the user-facing protocol carries the field that makes it work. The send method on MTProto takes a schedule_date, documented as the scheduled message date for scheduled messages, alongside a repeat period that re-sends the same message a set number of seconds later. Set it, and Telegram holds the message.
The Bot API has no equivalent. Its own send method takes seventeen parameters and not one of them names a send time — true of the version current in August 2026, and true of every earlier release in the changelog, which is a thing you can check yourself in about a minute rather than take from us. So when a hosted panel advertises a telegram post scheduler running on a bot token, the product is the vendor's queue on the vendor's server, waking up at the right minute to call the ordinary send method. It works fine. It also means your nine o'clock post depends on their nine o'clock uptime, and that is a question worth putting to a sales page directly.
Telegram closes the door explicitly rather than by omission. The protocol answers SCHEDULE_BOT_NOT_ALLOWED, glossed as bots cannot schedule messages, and the methods for reading and firing a scheduled queue both state that only users can call them.
Telegram schedule post, telegram scheduled post, telegram scheduler and telegram scheduling app are four ways of typing one question, and the answer splits the same way everything else here does: the client already does it for one chat, and a tool earns its price only when the job is many accounts, many destinations, a repeating loop, or an approval step in between.
Two documented refusals are worth knowing before you plan a queue. Telegram's error reference lists SCHEDULE_TOO_MUCH as there being too many scheduled messages, and SCHEDULE_DATE_TOO_LATE as scheduling a message too far into the future. Neither entry carries a number. So the per-chat caps and one-year horizons quoted around this category are operators comparing notes, not published policy, and we label them that way rather than repeat them as rules.
Being specific about our own side: scheduling lives in exactly one of the twenty-five modules here. The Group Message Blaster posts on a schedule in text, forward or PostBot mode, with loop options. There is no scheduled-DM module, and we would rather say that than let a feature grid imply one.
Which refusal does a marketing run meet first?
Whichever one belongs to the surface you picked, and they are not the same failure.
On the bot side the ceiling is throughput, and Telegram publishes it. The bot FAQ asks for no more than one message per second in a single chat, caps a bot at twenty messages a minute in a group, and says bots cannot broadcast more than about thirty messages per second for bulk notifications before the errors start. Those are numbers you can design a queue around.
On the account side there is no published figure at all, the refusals arrive in a different order, and they are a subject of their own we have already taken apart. A telegram auto message sender and a telegram auto sender are the same listing with a word removed; what separates the products underneath is which of those two failure modes they were built to survive.
The feature grid every directory prints, and the column it leaves out
Every roundup in this category runs the same six rows. Member adder. Scraper. Bulk sender. Auto-poster. Multi-account. Analytics. Each row is true of something, and the grid never says of what, which is how two products that cannot do the same work end up in the same table with the same ticks.
The column nobody prints is the one that decides the rest: what does this thing sign in as?
Here is the version we would actually use, written as checks rather than features. Each row is one question, short enough to send in a message. The answer either lands or it does not.
| What you are checking | How to check it before paying | What disqualifies the tool |
|---|---|---|
| What it signs in as | Does setup ask for a token or a number? | A token, if you need to reach people who never wrote to you |
| First contact with a stranger | Ask which method it calls to open the chat | Any answer that names the Bot API |
| Where a scheduled item waits | Ask whether Telegram holds it or the vendor does | Vendor-side, if their downtime is your downtime |
| Where sessions live | Ask what leaves the machine, and when | Credentials uploaded to a panel you do not run |
| Behaviour on a wait | Ask what happens to the other accounts meanwhile | Retrying the same account into the same error |
| Proxy handling | Ask whether a proxy binds per session or per pool | One shared address behind every account at once |
The third column is the one that saves money. A feature list describes a good day, and every product in this category has good days. Products separate on the shape of a bad one: a chat that refuses the post on arrival, a server telling one account to wait ninety seconds, a list where a third of the usernames resolve to nobody. Those are the moments a grid was never designed to describe, and they are most of the operating experience.
Run the checks against a demo rather than a specification sheet, if you can get one. A vendor who will screen-share a live run with real refusals in the log is telling you more than any page of copy, because the log is the part nobody writes marketing for.
It is also worth saying where the work actually starts, because the grid puts sending at the top and sending is the last step. The audience list exists before any of this runs, and an export you can actually filter decides more about a campaign than the sender does. Posting into rooms is a third job again, with its own ceiling: joining runs out before pacing does.
Is bulk telegram marketing against the terms of service?
The unsolicited part is, in plain words. Telegram's terms of service ask you to agree not to use the service to send spam or scam users, and the spam FAQ describes what follows for accounts that write unwanted messages to strangers: the ability to do it is withdrawn, briefly at first, for longer if it continues.
Posting to a channel people chose to subscribe to is a different act, and that FAQ is not about it. Both live inside most definitions of Telegram marketing, which is precisely why the category needs the distinction drawn rather than blurred.
Drawing it is also the only way the risk question becomes answerable. Broadcasting to subscribers is bounded by throughput and by whether the content itself breaks a rule. Writing to strangers is bounded by their patience, since the reports that end an account come from recipients rather than from a scanner. You can plan for the first; the second is a decision about the list.
Free, cracked or nulled: three different things to buy
Only one of the three is a coherent thing to want, and the other two are not even the same object as each other.
Free is real. On the account side much of it is open source: libraries and scripts you can read before running, maintained by people who publish their changes. The price is your own time, paid on the week a protocol layer moves and something quietly stops resolving. Calling that option worthless would be selling rather than advising, so we will not.
Now the other two, which get typed as if they were synonyms. Nulled is a web-script word. Anything circulating as telegram marketing tools nulled is almost always a self-hosted panel, usually PHP, with its licence check removed, which you then have to put on a server and point at credentials of your own. Cracked is a desktop word: telegram marketing tools cracked and telegram marketing software cracked return patched Windows binaries that run on your machine. A hosted service has neither shape, because there is no file in your hands to patch — you were renting a seat on somebody's server the whole time.
So the piracy searches split along the same line as everything else here, and that split tells you more than the licence question does. A nulled panel is a hosting problem and a database of your credentials sitting on a box you configured at midnight. A cracked build is a binary problem, running with whatever permissions your Windows user has. All three share one thing: somebody you cannot identify has edited the code you are about to hand a live credential to, and that argument is made properly elsewhere rather than repeated here.
There is one failure Telegram names directly, though, and it belongs in a buying decision. Every account-side tool needs API credentials, and Telegram's page on obtaining them warns that a published credential produces the API_ID_PUBLISHED_FLOOD error for everyone using it, and states that using the API for flooding or spamming gets the account banned forever. A build passed around a forum is, by definition, running a credential that has been published. The people who eventually meet that error are its users, and they will not be told why.
What a licence buys, and what it does not
Pricing in this category comes in four shapes and they are hard to compare on purpose. Per message, which is how hosted panels bill and how a large campaign quietly becomes expensive. Per member delivered, which is a growth service wearing software's clothes. Per seat, per operator. Or one flat licence for the build, which is what the desktop half is sold for here, with every module inside it and no per-send meter running.
The cheap listings are usually selling a different object rather than the same object discounted: a single-purpose sender, a one-off script, a seat on a shared panel. Compare what is included before comparing the currency. How many modules, whether updates arrive, who holds the sessions, and what happens the week Telegram changes something and the tool stops working. A build nobody maintains stops being cheap on its first broken Tuesday.
Then the part we would rather say plainly than have you discover.
This software raises no Telegram limit. Those limits sit on Telegram's servers and apply to every client that speaks the protocol, ours included. The only documented ways any of them move are Telegram's own paid mechanisms — a bot enabling paid broadcasts, or Premium lifting a specific wait — and neither is something a desktop build can switch on for you. Accounts and proxies are not ours to supply. Nothing here makes a bot write to a stranger, and we will not put a delivery number in front of you, because nobody selling in this category can honestly know one.
The rest is the boring, checkable part: Check Accounts and SpamBot Check tell you which sessions are clean before a run rather than after it fails, Account Warmup builds history on a new number instead of pretending it has one, and every other module in the suite shares the same session pool, the same pacing engine and the same log. Sessions and exports stay on the machine. None of those are outcomes we are promising you; they are behaviours you can watch in the log while a run is going.
Ask a vendor the four questions in the table above. If the answers are vague, the product is the vagueness.