Разбор строки выдачи: поля, разделители и первый вход
После оплаты заказ приходит одним текстовым блоком: сколько аккаунтов в заказе, столько и записей. Читать его удобно слева направо — порядок блоков у всех партий Nordi одинаковый, меняется только их набор. На срезе 6 сентября 2026 года в наличии 71 позиция, и вся выдача по ним укладывается в один скелет.
Две черты делают разную работу
Двойная черта || отделяет аккаунт от аккаунта. Так приходят партии под менеджеры аккаунтов: вся выдача лежит одним контейнером, и переводов строки внутри него может не быть вовсе. Одиночная | режет запись на блоки. Разница практическая: если разобрать файл только по переводам строки, контейнер на 500 аккаунтов останется одной записью, и импорт увидит в нём один аккаунт вместо пятисот.
Порядок блоков внутри записи фиксирован: голова, User-Agent, устройство, заголовки. У строковых партий блоков два — голова и куки. Пустое место между чертами (в конце записи это выглядит как |||) означает не поломанный файл, а поле, которого у партии нет: позиция сохранена, чтобы разбор не съехал на соседний блок.
Перед импортом есть смысл сверить одно число: сколько записей получилось после разбиения по || и переводам строки. Оно должно совпасть с количеством оплаченных аккаунтов. Расхождение вниз почти всегда значит, что разбор сделан не по той черте; расхождение вверх — что в файле остались пустые строки. И то и другое видно до первого входа, а не после него.
Голова: логин, пароль и два необязательных поля
Голова разделена двоеточиями. Первое поле — логин, второе — пароль. Дальше начинается место, где разбор чаще всего ошибается: третьим полем может стоять и адрес почты, и ключ 2FA, и порядок у разных партий разный. Опознаются они по виду, а не по позиции.
- Почта видна по знаку
@. Поле сразу за ней — пароль от почты, отдельной пометки между ними нет. - Ключ 2FA записан в base32: только буквы A–Z и цифры 2–7, от двенадцати знаков. Это не шестизначный код из приложения, а секрет, из которого код считается. В форму подтверждения идёт результат генератора, а не сама строка.
Сегодня почта вынесена прямо в поле формата у двух позиций — IAM|Email:EmailPass и Login:Pass:2FA_code|Cookie|Email:EmailPass. Ключ 2FA стоит в голове у четырёх. Метка 2FA в названии партии говорит о состоянии аккаунта, а не о составе строки, поэтому сверять нужно поле «Формат»: оно перечисляет ровно то, что придёт.
Второй блок: куки или User-Agent
Что стоит вторым, зависит от семейства формата. У строковых партий это куки — пары имя=значение через точку с запятой; таких позиций в стоке 32, из них 28 идут как Login:Pass|Cookie. У менеджерских партий вторым идёт User-Agent, длинная строка вида Instagram 364.0.0.18.86 Android (29/10; 420dpi; 1080x2138; …). Внутри неё восемь точек с запятой, поэтому резать запись по ; нельзя — развалится сам User-Agent.
Имён кук в выдаче встречается десять: csrftoken, sessionid, ds_user_id, mid, datr, ig_did, rur, shbid, shbts, ig_nrcb. Сессию держит sessionid. Числовой идентификатор профиля ds_user_id дублируется внутри неё — это часть до последовательности %3A. Если отдельной кукой он не пришёл, его берут оттуда, и это не потеря данных.
Порядок кук внутри блока не закреплён, и полный набор из десяти имён встречается редко. Искать их нужно по имени, а не по номеру поля: у соседних записей одной партии состав может отличаться на две-три куки.
Третий блок: устройство
Третий блок есть только у менеджерских записей. Выглядит он как android- и шестнадцать шестнадцатеричных знаков, а за ним три UUID через точку с запятой — четыре идентификатора подряд. Это отпечаток устройства, к которому привязана сессия. Он задуман постоянным для конкретного аккаунта: переносить запись между запусками нужно целиком, вместе с этим блоком.
Четвёртый блок: заголовки
Последний блок — заголовки запроса, тоже через точку с запятой: X-MID, X-IG-WWW-Claim, IG-U-DS-USER-ID, Authorization, IG-INTENDED-USER-ID. Смысловой здесь один. В Authorization лежит Bearer IGT:2: и дальше base64, внутри которого JSON ровно из двух значений — ds_user_id и sessionid. Из этого следует практический вывод: менеджерская запись без куки-блока всё равно несёт сессию, просто в другом месте.
Значение X-IG-WWW-Claim=0 означает, что claim ещё не выдан — его присылает сервер в ответ на первый запрос. Ноль на входе это нормальное состояние свежей записи, а не признак испорченной выдачи.
IAM и IGAM: разница не в строке
Разобранные по полям, эти два формата совпадают — те же блоки в том же порядке, тот же способ хранения сессии. Различие лежит в описании позиции: у IGAM прописана оговорка про использование только в InstAccountsManager, у IAM без приставки такой оговорки нет. На сегодняшнем стоке IGAM занимает 21 позицию, IAM в трёх вариантах — двенадцать, INSTAMEN — две. Итого 35 менеджерских записей из 71; ещё 32 позиции приходят строкой, а четыре — это User-Agent-строки, а не аккаунты.
Когда блока нет
| Чего не хватает | Как это видно в записи | Что с этим делать |
|---|---|---|
| Куки-блока | Сразу за головой идёт User-Agent | Формат IAM (без Cookie), две позиции в стоке. Сессия достаётся из Authorization |
| Почты | Хвост записи пуст: две черты подряд | Восстановления по почте по этой партии нет; поле не потеряно, его в партии не было |
| Ключа 2FA | Голова из двух полей | Двухфакторную защиту подключают своим ключом уже после входа |
| User-Agent | Вторым блоком идут куки | У куки-выдачи родного устройства нет вовсе; отпечаток задаёт тот софт, куда её импортируют |
ds_user_id | Отдельной куки с таким именем нет | Берётся из sessionid, часть до %3A |
Что из этого меняет первый вход
Порядок действий диктует не формат, а место, где лежит сессия. Когда она в куках, профиль сначала получает прокси, потом куки, и только после этого открывается страница: вкладка, открытая до импорта, уходит с чистым отпечатком и обнуляет смысл готовой сессии. Когда сессия в Authorization, порядок тот же, но импорт идёт в менеджер аккаунтов, а не в браузер.
Конвертер форматов на витрине переводит выдачу между этими видами прямо в браузере, без отправки данных наружу: куки в мобильную сессию, обратно, и куки в JSON-массив с доменом, путём, флагами secure и httpOnly и датой истечения. Последний вид — тот самый, который антидетект-браузеры принимают при создании профиля: в AdsPower такой массив вставляется в поле cookies карточки профиля.
Правильно разобранная строка обычно открывается с первой попытки. Если разбор верный, а аккаунт не пускает, это случай, на который действует замена невалидов за 30 минут: в обращении нужны номер заказа и сама строка — по ней видно, какого блока не хватило.
Поле «Формат» стоит в названии каждой позиции, поэтому состав строки виден до оплаты. Значения меток собраны в справочнике, а перевести уже полученную выдачу между видами можно в конвертере форматов.