Telegram bot development
Telegram bot development — serious bots, built by engineers.
Appsarmy is a Telegram bot development company for teams that can tell the difference between a script and a system. We build on the Bot API — webhooks, inline keyboards, the Payments API, and rate-limit-aware broadcasting — and reach for MTProto only when the Bot API genuinely can't do the job. It's an applied corner of our AI development practice, where a bot is often the chat surface for an LLM agent.
What we build into a Telegram bot.
A bot that answers /start is a weekend project. The gap between that and something a business runs on is state, payments, throughput, and integration — the parts that only show up under load. Our Telegram bot development services cover all of them.
Conversational flows & state
Telegram delivers each update in isolation and keeps no memory of your conversation. We build the state machine that does — keyed per chat, persisted in Redis or Postgres — so a multi-step flow survives a restart, a timeout, or a user who wanders off mid-checkout.
Stateful flows, not stateless repliesInline keyboards & callback queries
Buttons attached to a message send a callback query — up to 64 bytes of callback data — not a new chat message. We wire these to real actions, answer every query so the client's loading spinner clears, and edit the message in place. That's the difference between an interface and a wall of text.
Buttons that do somethingTelegram Payments
Invoices through the Payments API with a provider token from a real payment provider, plus the pre-checkout handler that has to answer within seconds.
Broadcast & notifications
Fan-out to thousands of users inside the Bot API's rate limits, through a queue that backs off on a 429 instead of getting the bot throttled.
Backend & LLM integration
The bot stays a thin surface over your systems — CRM, ERP, or an LLM agent — with the business logic where it belongs, on your server.
What Telegram's encryption actually protects.
This matters because the old marketing line — that a Telegram bot is safe because Telegram is "end-to-end encrypted" — is simply wrong. End-to-end encryption on Telegram applies only to Secret Chats, which are device-to-device and which bots cannot use at all. Every message to or from a bot is encrypted in transit, but it is readable on Telegram's servers and again on your backend. So protecting anything sensitive is an application-layer job: TLS on the webhook, a secret token so you can verify a request really came from Telegram, and payment card data handled by the payment provider rather than parked in a chat. We design for that reality instead of hiding it — which is the same discipline we bring to fintech and banking work.
Webhooks or long polling: how updates reach your bot.
There are exactly two ways for a bot to receive updates, and the choice shapes the whole deployment.
Webhooks (push)
Telegram POSTs each update to an HTTPS endpoint you expose. It needs a valid TLS certificate on one of four ports — 443, 80, 88, or 8443 — and a handler that returns quickly, because Telegram retries on a slow or failed response. It scales cleanly and sits idle at no cost between messages. This is our default for anything in production.
Event-driven, production-readyLong polling (getUpdates)
Your bot calls getUpdates in a loop and Telegram holds the connection open until something arrives. No public endpoint and no certificate needed, which makes it ideal for local development and low-volume internal bots. Only one poller can run at a time, so it doesn't scale horizontally without care.
Simple, great for buildingYou can't run both at once — setting a webhook disables getUpdates until you delete it. We usually build and debug on long polling, then switch to a webhook, secured with a secret token, for the deployment.
Rate limits, and the broadcast architecture they force.
Telegram's limits are generous until you hit them, and then they're a hard wall. Broadcasting to a large audience is really an exercise in respecting them.
~30 messages / second
The broad ceiling for messages to different users. Push past it and Telegram replies with a 429 and a retry_after telling you how long to wait.
~20 / minute, per group
Messages into a single group chat are capped far lower. A chatty group bot has to pace itself or it goes quiet.
A queue, not a for-loop
Broadcasts run through a rate-limited queue with a worker pool and backoff on 429, so a send to thousands lands over seconds rather than all at once into a throttle.
You can't message first
A bot can only message users who have started it. Notification systems are built around that opt-in, not around a contact list.
When the Bot API is enough, and when you need MTProto.
Most bots should be built on the Bot API. Some jobs genuinely can't be, and knowing which is which saves a rewrite.
The Bot API — the right default
The HTTPS interface most bots should use: stable, well-documented, and safe by design. A bot can't read a group's full history without being an admin, can't start a chat with a user first, and moves files within the API's limits — downloads up to 20 MB, uploads up to 50 MB. Those are guardrails, not obstacles, for the vast majority of bots.
Stable, supported, safeMTProto — when you truly need it
The low-level protocol behind a real user account. A user-bot built on MTProto — via TDLib or a client like Telethon — can do what the Bot API deliberately won't: act as a user, read large histories, move very large files. It also runs on a user account, with the account-ban risk and Terms-of-Service weight that carries. We reach for it only when the requirement demands it, and we tell you the tradeoff plainly.
Powerful, used with careNine times out of ten the honest answer is the Bot API. When it isn't, we'll say so — and say why.
From /start to a bot on call.
Scope
The flows, the integrations, and the load — and what the bot must never get wrong, written down first.
Framework
The right library for the job — aiogram, python-telegram-bot, grammY — with webhook or polling decided by where it will run.
Conversation
State machine, inline keyboards, and callback handling built and tested against the awkward paths, not just the happy one.
Integrations
Payments, your backend, and any LLM or data services wired in behind the bot, where the logic belongs.
Harden
Webhook secret token, input validation, rate-limit-aware sending, and structured logging for every update.
Deploy & watch
Shipped on your infrastructure with health checks, so a dead webhook is an alert, not a silent outage.
The Telegram stack we build on.
A bot team that reads the API docs, not the brochure.
Depth over demos
We build the parts that only matter under load — state, retries, rate limits — because that's where a real bot lives or dies.
Honest about security
We'll tell you plainly what Telegram encrypts and what it doesn't, and design the sensitive parts accordingly rather than around a myth.
Bot API first
We use the supported, stable interface by default, and reach for MTProto only when the job truly needs it — never for its own sake.
Software engineers first
A bot is a backend with a chat interface. Ours is built by people who also ship the server, the integrations, and the app around it.
Work with us the way that fits.
Bot build, fixed scope
A defined bot — flows, payments, integrations — with a written scope and a clear price.
Bot + backend
The bot and the service behind it, built together as one system rather than bolted together later.
Rescue & scale
An existing bot that's flaky, throttled, or stuck on polling — audited, hardened, and moved to webhooks.
Telegram bot development questions.
Do you build bots with the Bot API or MTProto?
The Bot API by default — it's stable, supported, and safe for almost every bot. We use MTProto, via TDLib or Telethon, only when a requirement genuinely needs a user account, large file transfers, or history access the Bot API won't grant.
Should my bot use webhooks or long polling?
Webhooks in production: Telegram pushes updates to an HTTPS endpoint with a valid TLS certificate on port 443, 80, 88, or 8443. Long polling is simpler and great for development and low-volume bots. You can't run both at once.
Are Telegram bot messages end-to-end encrypted?
No. End-to-end encryption on Telegram is limited to Secret Chats, which bots can't use. Bot messages are encrypted in transit but readable on Telegram's servers and on your backend, so sensitive data is protected at the application layer, not by Telegram's encryption.
Can a Telegram bot take payments?
Yes, through the Payments API. The bot sends an invoice using a provider token from a connected payment provider and answers the pre-checkout query before the payment completes. Card data is handled by the provider, not stored in the chat.
How many messages can a bot send?
Broadly around 30 messages per second overall, and about 20 per minute into a single group. Broadcasts run through a rate-limited queue that backs off when Telegram returns a 429, so large sends land without throttling the bot.
How do you handle multi-step conversations and buttons?
With a state machine keyed per chat and persisted, plus inline keyboards whose callback queries drive the next step. Each query is answered so the client clears its spinner, and messages are edited in place rather than stacked.
Let's build your Telegram bot.
business days