Что такое журнал действий и где он лежит
В интерфейсе это пункт «Недавние действия» в настройках супергруппы. В протоколе — отдельная страница документации /api/recent-actions и метод channels.getAdminLog. Формулировка первоисточника: журнал недавних значимых действий в супергруппе и канале, вроде изменения настроек и информации от лица админа, киков и банов.
Ключевое слово — «и ещё». Список того, что туда попадает, за годы разросся сильно шире банов и киков, и половина записей относится к вещам, о которых владельцы чатов обычно не думают.
channelAdminLogEvent с четырьмя полями: id, date, user_id и само действие. user_id — тот, кто это сделал. Именно поэтому журнал персональный: не «кого-то добавили», а «вот этот аккаунт добавил вот этого человека тогда-то».Кто может открыть журнал
Только администратор. Я сверился со справочником ошибок api/errors.json: у метода channels.getAdminLog прописана ошибка CHAT_ADMIN_REQUIRED сразу в двух кодах, 400 и 403, с расшифровкой «You must be an admin in this chat to do this». Плюс CHANNEL_PRIVATE для случая, когда ты в чат даже не вступил.
Отдельного права под журнал в Telegram нет — не нужно ни «банить», ни «удалять сообщения», достаточно быть админом с любым набором галочек. Для инвайтинга это значит простую вещь: журнал читает не только владелец, а любой из десятка админов, которых владелец назначил и забыл.
Какие 52 события Telegram записывает
Полный список конструкторов лежит в типе ChannelAdminLogEventAction. На снимке от 11 сентября 2026 года их ровно 52. Разложил по смыслу:
| Группа событий | Штук | Что попадает |
|---|---|---|
| Настройки и ограничения | 20 | название, описание, @юзернейм, аватар, слоумод, автоудаление, запрет пересылки, нативный антиспам, скрытая предыстория, права по умолчанию |
| Участники и права | 9 | вошёл, вышел, приглашён, вход по ссылке, вход по заявке, бан и разбан, назначение и снятие админа, смена тега |
| Звонки и трансляции | 6 | старт и завершение, мьют и размьют участника, громкость, настройки звонка |
| Сообщения | 5 | отправка в канал, редактирование, удаление, закрепление, остановка опроса |
| Оформление | 5 | цвет сообщений, цвет профиля, обои, эмодзи-статус, набор кастомных эмодзи |
| Темы форума | 4 | создание, редактирование, удаление, закрепление темы |
| Ссылки-приглашения | 3 | создание, редактирование, отзыв и удаление инвайт-ссылки |
Про редактирование и удаление стоит сказать отдельно. Событие EditMessage хранит оба состояния — prev_message и new_message. Удалённое сообщение тоже уезжает в лог целиком. Так что «отредактировал и никто не заметил» работает для ленты чата, но не для админа, который открыл журнал.
Оставляет ли парсинг след в журнале
Нет. Я прогнал все 52 конструктора поиском по корням view, read, fetch, export и scrape — совпадений ноль, если не считать событий про инвайт-ссылки, где слово exported относится к самой ссылке, а не к выгрузке данных.
Логика тут простая и от неё же следует отталкиваться: журнал фиксирует изменения состояния чата. Кто вошёл, кого лишили прав, что переключили в настройках. Открытие списка участников состояние чата не меняет, поэтому записывать нечего. То же касается чтения истории сообщений и сбора комментаторов.
Из этого вытекает граница, которую стоит держать в голове при любой работе с чужим чатом: смотреть — тихо, трогать — громко. Наш парсер аудитории живёт на первой половине: собирает участников, писавших и комментаторов от лица обычного вступившего пользователя, и в журнале от этого появляется ровно одна строка — сам факт вступления аккаунта. Дальше он молчит. Подробнее про то, что вообще отдаёт платформа, а что нет, — в разборе скрытого списка участников.
Как в журнале выглядит инвайтинг
А вот здесь всё наоборот. Приглашение — это изменение состава, и записывается оно подробно. Четыре разных события на четыре способа появления человека в чате:
| Событие | Что произошло | Что видно админу |
|---|---|---|
ParticipantJoin | человек зашёл сам | в больших группах данные вошедшего в записи не показываются — прямая оговорка документации |
ParticipantInvite | его добавили | кто добавил и кого — участник лежит в поле, автор действия в user_id записи |
ParticipantJoinByInvite | вошёл по ссылке | конкретная ссылка в поле invite, отдельный флаг via_chatlist для ссылки на папку |
ParticipantJoinByRequest | заявку одобрили | ссылка плюс поле approved_by — какой именно админ впустил |
Разница между первой и второй строкой и есть вся суть. Самостоятельный вход в большом чате обезличен. Приглашение — именное, и рядом с ним стоит аккаунт, который его сделало. Сто приглашений подряд с одного номера складываются в журнале в сплошную колонку с одним и тем же именем, и открыть её админу — два тапа.
Поэтому в обычном инвайтинге аккаунты разводят по группам и льют небольшими порциями: это не суеверие, а попытка не выглядеть колонкой. Ту же природу имеет и режим заявок на вступление — он переводит вход в разряд решений админа и заодно даёт ему список тех, кто рвётся в чат.
Почему добавление через админку тоже видно
Есть известный обходной приём: агент с правом назначать админов делает цель администратором — так человек попадает в чат мимо настройки приватности «кто может меня добавлять», — а сразу после разжалует обратно. В участниках остаётся, галочек не имеет.
В журнале это не невидимость, а две записи вместо одной. Событие ParticipantToggleAdmin срабатывает на назначение и ещё раз на снятие, и каждое хранит prev_participant и new_participant, то есть права до и после. Пара «назначил-разжаловал» с интервалом в секунду выглядит в логе заметнее, чем обычный инвайт.
Честный вывод: приём решает проблему приватности, а не проблему следов. С точки зрения журнала он шумнее прямого добавления. Что с этим делать — вопрос не технический, а про то, в какие чаты идти и с какой интенсивностью; про цену ошибки мы писали в разборе за что Telegram банит аккаунты.
Что из этого видит бот-охранник
Админ-лог живёт в клиентском API, у ботов доступа к нему нет. Но часть тех же фактов Bot API отдаёт своим каналом — апдейтом chat_member с объектом ChatMemberUpdated. Состав полей по справочнику на 11 сентября 2026 года:
from— кто совершил действие, приведшее к изменению;old_chat_memberиnew_chat_member— статус до и после;invite_link— по какой ссылке вошли, только для входа по ссылке;via_join_request— человек пришёл заявкой без ссылки, и его одобрил админ;via_chat_folder_invite_link— вход через ссылку на папку чатов.
Две оговорки, из-за которых половина ботов этих апдейтов не получает. Бот обязан быть администратором чата, и тип chat_member надо явно перечислить в allowed_updates: в документации сказано, что пустой список включает всё, кроме chat_member, message_reaction и message_reaction_count. По умолчанию бот про новых участников попросту не знает.
Отсюда практический момент: чат без бота-охранника и с необновляемым составом админов фактически никто не читает, даже если журнал там пишется исправно. А чат, где сидит настроенный модерационный бот, реагирует на поток в реальном времени. Это разные цели по сложности, и понять, какая перед тобой, можно до начала работы.
Чем админ фильтрует журнал
Тут стоит понимать масштаб. У метода есть объект channelAdminLogEventsFilter с 20 флагами: join, leave, invite, ban, unban, kick, unkick, promote, demote, info, settings, pinned, edit, delete, group_call, invites, send, forums, sub_extend, edit_rank. Плюс два параметра, о которых редко вспоминают:
admins— показать действия только выбранных администраторов;q— строковый запрос, лог можно искать по тексту.
Фильтр invite — один тап, отделяющий приглашения от всего остального шума. А q позволяет искать по журналу конкретное имя. В официальных клиентах эти возможности разложены по интерфейсу, но сам факт, что они есть в протоколе, полезнее: владелец чата не обязан листать тысячи строк, чтобы заметить закономерность.
Сколько журнал хранится
В открытой документации срок хранения не опубликован. Я проверил страницу /api/recent-actions, описание метода channels.getAdminLog и FAQ на telegram.org — числа нет ни в одном месте. Цифры, которые кочуют по статьям про телеграмм, ни на один первоисточник не опираются, поэтому здесь их не будет.
Что в документации есть: пагинация через max_id и min_id с параметром limit. Верхняя граница глубины в описании не задана. Значит исходить лучше из худшего варианта: запись останется доступной админу и через неделю, и через месяц.
Что с этим делать на практике
- Разделяй сбор и добавление. Первое журнал не видит вовсе, второе видит поимённо. Планировать их как один процесс с одинаковым уровнем риска — ошибка.
- Считай не общий объём, а объём с одного аккаунта. В логе колонкой выглядит не тысяча инвайтов, а тысяча инвайтов от одного имени.
- Смотри на чат до старта. Включён ли нативный антиспам, есть ли режим заявок, сидит ли модерационный бот — всё это меняется админом и всё это записано в том же журнале.
- Не рассчитывай на невидимость приёма с промоутом. Он обходит настройку приватности, а не журнал, и оставляет две записи вместо одной.
У нас инвайтинг живёт отдельным инструментом — TG Pulse: аккаунты разводятся по группам, у каждой группы свой источник прокси и своя скорость. Аккаунты под это берутся из каталога и проверяются в момент выдачи, адреса — резидентные или мобильные 4G. А парсер отрабатывает раньше, на той стадии, где журнал ещё молчит.
Частые вопросы
Видно ли в Telegram, кто пригласил человека в группу?
Да, если это супергруппа или канал. В админ-логе есть отдельное событие channelAdminLogEventActionParticipantInvite с описанием «A user was invited to the group», а у каждой записи журнала есть поле user_id — тот, кто совершил действие. То есть пара «кто пригласил — кого пригласил» лежит в логе готовой строкой. Открыть её может любой администратор чата.
Остаётся ли след в журнале, если просто собрать список участников?
Нет. В типе ChannelAdminLogEventAction 52 конструктора, и ни одного про чтение, просмотр или выгрузку. Журнал фиксирует изменения: кто вошёл, кого забанили, что поменяли в настройках. Открытие списка участников изменением не является, поэтому в лог не попадает. Проверено по core.telegram.org/type/ChannelAdminLogEventAction 11 сентября 2026 года.
Кто может открыть журнал действий администратора?
Только администратор чата. Метод channels.getAdminLog отдаёт ошибку CHAT_ADMIN_REQUIRED («You must be an admin in this chat to do this») и с кодом 400, и с кодом 403. Обычный участник журнал не увидит вообще, отдельного права админа под это не выделено — достаточно быть админом.
Сколько хранится журнал действий в Telegram?
В открытой документации срок хранения не опубликован. Ни страница core.telegram.org/api/recent-actions, ни описание метода channels.getAdminLog, ни FAQ на telegram.org числа не называют. Цифры, которые ходят по форумам, ничем из первоисточников не подтверждаются, поэтому мы их не повторяем. В методе есть пагинация через max_id и min_id, но верхней границы глубины там не задано.
Чем вход по ссылке отличается в логе от обычного вступления?
Это три разных события. ParticipantJoin — человек зашёл сам, и у больших групп данные вошедшего в записи не показываются. ParticipantJoinByInvite — вход по конкретной инвайт-ссылке, сама ссылка лежит в поле invite, а флаг via_chatlist отмечает вход через ссылку на папку чатов. ParticipantJoinByRequest — заявка, одобренная админом, и там же поле approved_by с тем, кто её принял.
Видит ли бот-администратор те же события, что и админ-лог?
Частично и по другому каналу. В Bot API есть апдейт chat_member с объектом ChatMemberUpdated: поле from — кто совершил действие, invite_link — по какой ссылке зашли, via_join_request и via_chat_folder_invite_link — булевы признаки заявки и папки. Чтобы эти апдейты вообще приходили, бот должен быть администратором и chat_member надо явно перечислить в allowed_updates: по умолчанию он не приходит.
Определение журнала, конструктор channelAdminLogEvent, объект channelAdminLogEventsFilter с 20 флагами и параметры q и admins — со страницы api/recent-actions. Полный список из 52 конструкторов, оговорка про обезличенный вход в больших группах, поля via_chatlist, approved_by, prev_participant и new_participant — со страницы типа ChannelAdminLogEventAction (на ней указан Layer 223). Ошибки CHAT_ADMIN_REQUIRED и CHANNEL_PRIVATE у метода channels.getAdminLog — из машиночитаемого errors.json. Состав полей ChatMemberUpdated и правило про allowed_updates — со страницы bots/api. Всё снято и сверено 11 сентября 2026 года.