ГлавнаяБлогTDATA или session+json
🗂 Аккаунты · разбор форматов

TDATA или session+json: чем отличаются и что брать под задачу

Tdata — папка авторизации официального Telegram Desktop. Session+json — формат для софта: файл сессии плюс параметры устройства и api_id рядом. Внутри у них один и тот же ключ авторизации, отличается упаковка — поэтому одно конвертируется в другое офлайн. Ниже: что лежит в каждом формате, какой нужен твоему сценарию и почему json рядом с сессией важнее, чем принято думать.

Что такое tdata

Это рабочая папка десктопного клиента. Когда ты логинишься в Telegram Desktop, он складывает туда ключи авторизации и локальные данные. Скопировал папку на другую машину, подложил клиенту — он открылся уже залогиненным, без кода из SMS.

Отсюда и область применения: ручная работа. Прогрев, переписка, ведение каналов, всё, где человек сидит и кликает. Формат родной для официального клиента, а значит вопросов «что за странное приложение» у Telegram к нему меньше.

Минус ровно там же, где плюс: автоматизировать tdata неудобно. Библиотекам он в таком виде не нужен, им подавай сессию.

Что такое session + json

Session — файл, в котором лежит ключ авторизации и служебные данные подключения. Его понимают библиотеки автоматизации. Именно с этим форматом работает любой userbot: он открывает сессию и начинает действовать от имени аккаунта.

Рядом почти всегда лежит json — и вот он-то и есть недооценённая часть. В нём параметры, под которыми аккаунт представляется серверу:

🔑api_id / api_hashключи приложения, от имени которого работает аккаунт
📱device_modelкакое устройство «держит» аккаунт
⚙️app_version / systemверсия клиента и ОС
🌐lang_codeязык интерфейса

Если session отдали без json — считай, что тебе отдали половину. Параметры придётся придумывать самому, и аккаунт, который вчера был «Samsung на Android», сегодня станет «Desktop на Windows». Для Telegram это смена устройства.

Почему свой api_id — не мелочь. В документации сказано прямо: тестовый ключ из открытого кода ограничен на стороне сервера и не годится для готовых приложений — использование его вне тестов даёт ошибку API_ID_PUBLISHED_FLOOD. Практически это значит: если у пачки аккаунтов один api_id на всех, они делят лимиты и падают вместе. Поэтому у аккаунтов, которые отдаём мы, ключи индивидуальные — в json рядом с сессией.

Что брать под какую задачу

ЗадачаФорматПочему
Ручная работа, прогрев, перепискаtdataРодной для Telegram Desktop, ничего конвертировать не нужно
Парсинг, userbot, своя интеграцияsession + jsonФормат, который понимают библиотеки автоматизации
Инвайтинг и рассылки через софтsession + jsonСофт обычно ждёт именно сессию с параметрами устройства
Не решил, что будет дальшеsession + jsonЛегко превращается в tdata, когда понадобится клиент

Конвертация: что это и чего это не

Конвертация между форматами — обычная операция. Ключ авторизации один и тот же, меняется только упаковка, поэтому переложить его из tdata в session и обратно можно офлайн, без единого запроса к Telegram. Аккаунт при этом ничего не замечает: для него ничего не произошло.

Это важно с точки зрения безопасности аккаунта. Операции, которые требуют обращения к серверу, всегда несут риск. Конвертация к таким не относится — она происходит у тебя на диске.

У нас это отдельный инструмент в боте: закидываешь tdata — получаешь session+json, и наоборот. Работает пачками, а не по одному аккаунту.

Дубликат сессии — отдельная история

Тут постоянная путаница. Скопировать файл сессии и запустить его в двух местах — это не «два аккаунта» и даже не две сессии: для Telegram это один и тот же вход, просто с двух машин. Конфликты и вылеты гарантированы.

Настоящий дубликат делается иначе — переподписью на другую пару устройства. Тогда в списке активных сессий аккаунта появляется отдельное устройство: например, одна сессия живёт как Desktop, вторая как iOS. Это законный сценарий, который поддерживает сам Telegram, — у обычного человека тоже стоят телефон и компьютер одновременно.

Как хранить файлы аккаунта

Файл сессии — это и есть доступ. Не пароль, который можно сменить, а готовый вход: у кого файл, у того и аккаунт. Отсюда несколько правил, которые дешевле соблюдать сразу.

  • Не таскать сессии через мессенджеры и облака «на минутку». Файл маленький, уходит незаметно и остаётся в истории переписки навсегда.
  • Держать пароль отдельно от сессии. Если облачный пароль лежит в json рядом, двухфакторная защита перестаёт что-либо защищать.
  • Не запускать одну сессию из двух мест. Это не два аккаунта, а один вход с конфликтом: Telegram будет разрывать соединения.
  • Проверять содержимое архивов. В выгрузках из macOS часто едет служебный мусор вроде __MACOSX и файлов с точкой в начале — софт принимает их за аккаунты и спотыкается.

И момент, который замечают поздно: если аккаунт уже где-то работал, в его активных сессиях может остаться чужое устройство. Заглянуть в список сессий после покупки — минутное дело, которое иногда экономит весь аккаунт.

На что смотреть при покупке

Формат — это упаковка. Аккаунт в идеальном tdata может оказаться со спам-блоком, а неказистая session — рабочей. У нас аккаунты отдаются в session+json со своим api_id, а tdata собирается конвертером в пару кликов. Поэтому по-настоящему важно другое:

Ещё один довод в пользу готового файла: авторизация в нём уже произошла. Стороннему софту получить код по SMS Telegram даёт не всегда — почему так и что при этом отвечает сервер, разобрано в статье «Не приходит код в Telegram».

Есть ли json рядом

Сессия без параметров устройства и своего api_id — сырьё, а не готовый аккаунт.

Когда проверяли статус

«Проверено на складе» неделю назад ничего не значит: за это время аккаунт мог словить ограничение. Мы проверяем в момент выдачи.

Чистый ли аккаунт прямо сейчас

Бан, ограничения, скрытые лимиты через @SpamBot — это то, что видно только живой проверкой. Как отличить типы ограничений.

Под чем он будет работать

Аккаунту нужен стабильный выход в сеть. Резидентный прокси на аккаунт держит географию ровной.

И маленькое замечание про поиск: половина людей ищет это словами «аккаунты телеграмм session json» через два «м». Формат от написания не меняется — а вот выдача меняется.

Дальше по теме: какие бывают типы аккаунтов и что значит «трастовый» и под каким прокси их запускать.

Частые вопросы

Чем tdata отличается от session+json?

Tdata — это папка авторизации официального Telegram Desktop: её кладут в клиент, и он открывается уже залогиненным. Session+json — формат библиотек автоматизации: файл сессии с ключом авторизации плюс json с параметрами устройства и api_id. Первый формат для ручной работы в клиенте, второй — для софта.

Что лежит внутри json рядом с session?

Параметры, под которыми аккаунт представляется Telegram: api_id и api_hash, модель устройства, версия приложения и системы, язык. Иногда номер и данные владельца. Если подставить чужие параметры, аккаунт начнёт выглядеть как другое устройство — это лишний повод для проверки.

Можно ли конвертировать tdata в session и обратно?

Да, конвертация работает в обе стороны и делается офлайн, без обращений к Telegram. Это не взлом: обе формы хранят один и тот же ключ авторизации, отличается только упаковка.

Какой формат покупать?

Под ручную работу в Telegram Desktop — tdata. Под любой софт, userbot или свою интеграцию — session+json. Если не уверен, бери session+json: из него всегда можно собрать tdata, и наоборот тоже, но начинать с формата под автоматизацию удобнее.

Почему у аккаунта должен быть свой api_id?

Потому что тестовый ключ из открытого кода ограничен на стороне сервера: Telegram прямо пишет, что использование его вне тестов даёт ошибку API_ID_PUBLISHED_FLOOD. Один api_id на сотни аккаунтов означает общие лимиты и общие проблемы.

Дубликат сессии — это то же самое, что копия файла?

Нет. Копия того же файла — это тот же вход с двух мест, и Telegram видит его как одну сессию. Дубликат создаётся переподписью на другую пару устройства, поэтому в списке активных сессий появляется отдельное устройство.

Про api_id и ошибку API_ID_PUBLISHED_FLOOD — из официальных правил получения api_id. Остальное — наша практика: конвертер и дубликатор сессий работают у нас в боте, и цифры взяты из того, как это устроено внутри.

Аккаунты в нужном формате — с проверкой при выдаче

Session+json или tdata, свой api_id в json, конвертация в обе стороны прямо в боте. Каждый аккаунт проверяется в момент покупки.