The Telegram API went down in Russia. Here's what we do with client bots - and why MAX is no longer a joke

TL;DR.After the restrictions on the Telegram Bot API in Russia, the "let's wait, they'll fix it" strategy stopped working for our clients with the very first one.

Over the past month we migrated several customer bots to MAX and VK and put together an honest map: where MAX already holds up as a replacement, where VK is stronger, and what's physically impossible to port one-to-one.

Next — a migration plan by bot type, a feature compatibility table for Telegram / MAX / VK, the pitfalls with webhooks, files, and inline mode, and our hands-on experience with the first projects on the MAX Bot API.

A separate section — about how bots are generally built in the max messenger and what you should not yet expect from them.

Where does this conversation even come from

Six months ago, the phrase "we'll move to MAX" in a discussion with a client sounded like a joke. Now it's an item on the roadmap that we are seriously agreeing on. The reason is mundane: on February 10, 2026, Roskomnadzor began throttling Telegram, andapi.telegram.orgwith a number of providers it gets blocked via the TSPU — deep traffic filtering equipment. Bots that for years quietly ran on webhooks from servers in Russian data centers suddenly stopped receiving responses from Telegram. The consequences depend on the type of business, but none of them are harmless:

• B2C sales— a drop in conversion, lost leads.
• Support— a queue of tickets that no one sees.
• Internal processes— stopping the routine the operations relied on.

We don't comment on the political side and we don't guess what comes next. But as a studio that has several clients' bots running in production, we're obliged to give them a working answer here and now. And that answer, as it turned out, doesn't come down to a simple "let's move the code and off we go."

MAX and VK are not clones of Telegram, they are different platforms with their own logic, their own API and their own audience. Migration is not copy-paste, but a small product redesign.

Below is what we have learned in practice, without marketing wrappers and without «MAX is the future». The future will show, but today we have specific clients who need their bot to accept requests again.

What the MAX messenger is and what bots in the MAX messenger have to do with it

In short and without the hype: MAX is a Russian messenger by VK that received national messenger status in July 2025 and has been actively expanding its functionality ever since.

From a developer's point of view, we're interested in one specific thing — the MAX Bot API, i.e. a set of methods through which you can programmatically read messages, reply to them, send media and build interactive scenarios.

Bots in the MAX messenger are conceptually similar to Telegram ones: there are commands, there are keyboards, there are webhooks and long polling, there's the ability to send buttons and handle taps. The difference begins in the details — and it's precisely these details that determine how painful the migration turns out to be.

The MAX Bot API is developing actively, and in some areas even outpaces Telegram:

• files up to 4 GB with resumable upload (versus 50 MB in the Telegram Bot API);
• inline keyboards with up to 210 buttons and 30 rows.

But at the same time, entire layers of familiar functionality are missing:

• inline mode (@bot query);
• native payments, stickers, reactions, polls;
• messages can only be edited within the first 24 hours;
• the text limit is 4,000 characters instead of 4,096.

A separate point— since August 2025, bots and mini-apps can be published in MAX only through verified Russian legal entities or sole proprietors.

Individuals and non-residents cannot yet pass verification, and this is worth keeping in mind at the start. For developing a MAX bot, all of this means that we design not a "Telegram replacement" but a channel into which the audience will gradually move over the coming months. Accordingly, UX decisions should be based not on today's familiar habits, but on how a person will open the bot for the first time in an interface that is new to them.

Another important thing— integrating the max messenger into the client's existing infrastructure. In most of our projects, the bot is not a standalone entity but a thin layer on top of the CRM, payment system, Payload CMS/Wordpress/Mobx/Strapi or an internal database. When we migrate a bot, we move not the dialogues but precisely this binding:

1. The webhook receives an event from the platform.
2. n8n or a custom backend processes it.
3. Next comes a trip to the CRM for the customer's data.
4. A response is formed and returned to the user.
5. Everything is logged for debugging and analytics.

That's why "moving to MAX" in our practice almost always means "carefully swapping the adapter in an already live architecture" rather than rewriting everything from scratch.

Feature comparison: Telegram Bot API, MAX Bot API and VK Bot API

To keep the conversation concrete, below is a summary table of the capabilities that most often turn out to be critical during migration. This is not an exhaustive reference but our working checklist: at the start of each project we use it to gauge how much functionality transfers "as is", how much will have to be reinvented, and what we'll have to give up.

The main takeaway from this table is the following:neither MAX nor VK cover the Telegram Bot API one hundred percent, and promising the client “full compatibility” means lying.

But in most practical scenarios that we encounter in our work, the migrated functionality fits within the intersection of all three platforms: text, media, keyboards, callback, webhooks.

Problems arise at the edges — where the project relied on inline mode, on native payments or on editing messages with no time limit.

How we migrate by bot type

There's no universal migration strategy, and any contractor offering "one plan for everyone" is simplifying the task to make it easy to sell. In practice we look at the type of bot and the priority it has for the business, and from that we build the order of actions. Our three most common cases look like this.

Sales and lead bots. 

This is the most sensitive category: every hour of downtime means lost leads and a direct loss. Here we don't wait for MAX to mature but take the path of parallel operation:

1. We keep the live Telegram bot running where it can still reach the user.
2. At the same time we bring up the MAX version with the same set of scenarios.
3. If the client has a community on VK — we add a VK bot as a third channel.
4. All three lead into one and the same lead queue in the CRM through a thin adapter that normalizes incoming events into a single format.

For the client, this means a single handling window; for the user, the ability to write wherever it's convenient for them. As a rule, for this kind of architecture we use n8n in the role of an event bus: it fits perfectly the scenario of "several sources → one funnel" and doesn't require writing the entire orchestrator by hand.

Support bots. 

The priority here is different. Not the speed of reacting to a lead, but the continuity of service for existing customers. Downtime is painful but not catastrophic — tickets can be caught up by email or phone. That's why we usually proceed sequentially:

1. first we roll out the MAX version
2. we move the FAQ scenario and the basic commands there
3. we test on part of the audience
4. we gradually migrate the rest

In parallel, we put a message in the Telegram bot (while it still works) like «we are now on MAX too» with a link, so that users switch of their own free will rather than under coercion.

Content bots. 

Mailouts, digests, notifications, content subscriptions. A category that seems simple at first glance, but actually has its own pitfalls.

The main one is the limits on broadcasts and the platform's attitude toward mass messaging. Telegram has historically been generous, while MAX and VK are stricter in this regard, and if we simply take the logic of "send to everyone on schedule" and transfer it literally, we'll quickly run into restrictions.

That's why for content bots we rework not the transport, but the mechanics:

• Pull model— the user requests fresh content themselves with a command or a button.
• Push only for urgent matters— we keep the broadcast for truly important notifications, not for every digest.

As a result, the migration turns out to be not a transfer but a small product redesign — but that's more honest than breaking down on the second mailing.

The general rule we took away from all three types: do not try to transfer the bot down to the last pixel detail. Some Telegram features are decisions made ten years ago for a specific UX, and in a new messenger they may not be the best choice, even if they can technically be replicated.

What breaks most often

There are three places where migration consistently runs into surprises. We already know them by sight and set aside extra time on every project, but if you're migrating a bot yourself, it's worth keeping them in mind from the very start.

First— it's webhooks. In the Telegram Bot API we got used to a webhook being configured with a single call, requiring HTTPS and generally forgiving a lot. The MAX Bot API and the VK Bot API are stricter about infrastructure.

Here's what differs in practice:

• An HTTPS certificate is needed — MAX accepts self-signed too, but VK requires a valid one.
• A stable public address, without interruptions — the platforms do not forgive downtime.
• Correct responses to verification requests during registration (with VK this is a separate confirmation mechanism via the Callback API).
• Proper handling of repeated deliveries — the platforms retry events slightly differently than Telegram.

In our migrations, we've several times run into a situation where the bot seemed to work but was losing some events because the backend responded with the wrong status code or didn't fit within the timeout. The problem is fixable, but you have to see it — and you can't see it without proper webhook logging. So the first thing we do during a migration is set up detailed logging of all incoming updates with the raw body and headers, at least for the first weeks of operation.

Second— files and media. The situation here is mixed. In terms of files, the MAX Bot API is objectively stronger than Telegram: a limit of up to 4 GB with resumable upload versus 50 MB in the standard Telegram Bot API. But the surprises lie elsewhere:

• Media upload in VK works through a separate upload server — this is a different sequence of requests, not a single callsendDocument.
• Not all formats are supported — some of the usual MIME types may not get through.
• The logic of handling attachments in MAX (attachments) differs from Telegram's, and code tied tofile_id, will have to be adapted.

If the customer bot had the logic of "take a file from the user, process it, send it back." This part needs to be rewritten taking the new mechanics into account, even if the size limits have become more generous.

In a number of cases, we move file handling out to an external URL: the bot gives the user a download link from our backend rather than trying to send the file through the platform's API. This is both more reliable and works the same way across all three channels.

Third— inline mode. This is perhaps the most painful loss. In Telegram, many interfaces are built on@bot query— the user invokes the bot directly from any chat, gets suggestions and sends the result to anyone. At the time of our migrations, the MAX Bot API does not provide this model in its familiar form, and neither does VK. If the client's product relied on inline as a key scenario, the honest answer sounds unpleasant: in the current version of the MAX Bot API it cannot be ported one-to-one, and we either change the UX to keyboards and commands inside the dialogue with the bot, or move the functionality into a mini-app.

We don't promise the client an "equivalent," because there isn't one; instead, we openly discuss which of the alternative scenarios actually solves the user's real task, rather than replicating the form of the familiar interface.

There's alsofourth, a less obvious spot is the dialogue state storage. In Telegram, many bots rely on the fact thatchat_idanduser_idare stable and unique, and they build their entire state machine on this. When migrating to another platform the identifiers change, and there are two options:

• Migrate the table to an abstractexternal_user_idwith a platform field — cleaner and immediately lays the groundwork for multi-platform support.
• Setting up separate tables for each channel is simpler at the start, but scales worse.

We prefer the first option. After this story with the API, multi-platform support no longer looks like a "nice bonus" but like mandatory insurance.

What we do differently after the first migrations

After several projects on the MAX Bot API, we've developed four practical principles that we now apply by default.

1. Multi-platform from day one.Even if the client today wants only MAX, we lay down an architecture in which adding VK or bringing back Telegram means connecting one more adapter, not rewriting the core. The transport layer (working with the platform's API) lives separately from the business logic (scenarios, states, CRM), and between them is a normalized event format. This approach doesn't add much work up front, but pays off the very first time the rules of the game change on any of the platforms.
2. Caution with UX promises.When a client shows a screenshot of a Telegram bot and says "make the same thing in MAX", we honestly go through the feature table and note: what carries over literally, what carries over with caveats, and what doesn't carry over at all. It's an unpleasant conversation, but it saves a month of arguments after launch.
3. Proper infrastructure.Bots that used to live as a single container on a small VPS are now standardly deployed in a Docker environment with a proper process manager, separate webhook logging, and adapter health monitoring. When it's not your code that fails but the upstream platform, you're obliged to see it first and notify the client before they notice it themselves.
4. MAX is not a temporary patch.We don't believe MAX will replace everything. But we saw this: the mere fact of having a working channel across several messengers at once is a different level of business resilience, and after that you don't want to go back to a single-platform architecture, even if Telegram starts working as before again tomorrow.

If you realize that your customer bot has become a pain point and want to calmly figure out how to move it to MAX and VK without losing functionality, we do this as part of the servicebot development for MAX. Come and discuss it — we'll look at your current bot, walk through the feature table as it applies to your scenario and show how the migration will look specifically in your case.