ЕИС в сфере закупок остается главным источником открытых данных по государственным и корпоративным закупкам, но сам порядок машинного получения этих данных изменился. С 1 января 2025 года привычный FTP-канал для выгрузки машиночитаемых данных закрыт. Вместо него используются сервисы отдачи информации и документов, а доступ к ним открывается только после регистрации и аутентификации через ЕСИА. Это закреплено постановлением Правительства РФ № 1740 и подтверждено официальными сообщениями ГИС ЕИС ЗАКУПКИ.
Дополнительно изменился и технический контур. С 26 ноября 2024 года вход для получателей машиночитаемых данных перенесли в личный кабинет получателя открытых данных в разделе открытых данных ЕИС. А с 6 июня 2025 года для интеграционного обмена начали использоваться новые домены; старые домены int44.zakupki.gov.ru и int223.zakupki.gov.ru были закрыты с 4 октября 2025 года. Это важная деталь: старые примеры из интернета и старые инструкции сегодня могут не работать просто из-за неактуального адреса.
Если убрать все лишнее, современная схема выглядит так: регистрация в ЕИС как получателя машиночитаемых данных → выбор правильного сценария доступа → SOAP-запрос к сервису ЕИС → получение ссылки на архив → скачивание архива по GET → разбор документов → загрузка данных в свою систему. Именно в таком виде сервис описан в актуальной инструкции ЕИС.
Какие есть варианты доступа
В ЕИС сейчас есть не один “API для всех”, а несколько сценариев работы. Для физических лиц и ИП используется сервис getDocsIP. Для юридических лиц — сервис getDocsLE. Для внешних систем размещения заказов, которым нужно получать документы конкретных организаций, предусмотрен отдельный сервис getDocsOrganization. Все три сценария относятся к одному механизму отдачи информации, но различаются способом аутентификации и составом параметров.
Это ключевое место, где чаще всего возникает путаница. Для физического лица основой доступа служит токен, который указывается в SOAP Header. Для юридического лица основой доступа служит не токен, а сертификат, загруженный при регистрации; в примерах для getDocsLE заголовок SOAP вообще пустой, потому что аутентификация происходит на транспортном уровне. Для ВСРЗ используется уже пара токенов: self_registry_token и organization_token. Поэтому один GUID сам по себе не является универсальным ключом доступа ко всем вариантам интеграции.
На практике это означает следующее. Если вы — обычная компания и хотите регулярно забирать открытые данные ЕИС в свою систему, самый понятный путь — сценарий юридического лица через getDocsLE. Если вы — физическое лицо или ИП, нужен getDocsIP. Если вы строите внешнюю систему, которая получает документы конкретных заказчиков или владельцев документов, тогда речь идет уже о getDocsOrganization и отдельной токенной схеме.
Что изменилось по сравнению со старой схемой через FTP
Раньше многие интеграции с ЕИС строились на регулярной загрузке XML-архивов с FTP. Это было просто, но никак не контролировало аутентификацию, цель использования и техническую нагрузку. Новый порядок сделал доступ более формальным: теперь нужно пройти регистрацию, подтвердить личность через ЕСИА и работать через сервисы, которые формируют архивы по запросу. Официальный канал ЕИС отдельно подчеркивал, что getDocsIP и getDocsLE были введены именно как замена старому FTP-механизму.
Из-за этого изменилась и архитектура интеграции. Раньше можно было просто скачивать ежедневные дампы. Теперь нужно уметь отправлять SOAP-запросы, ждать формирования архива, скачивать результат по ссылке и учитывать ограничения сервиса. Для внешнего потребителя это не катастрофа, но это уже полноценная интеграция, а не “простой парсер открытых файлов”.
С чего начать: регистрация и получение доступа
Первый шаг — зарегистрироваться в ЕИС как получатель машиночитаемых данных. По инструкции ЕИС для этого нужно зайти на главную страницу ЕИС, перейти в раздел открытых данных, открыть пункт получения открытых данных, затем пройти авторизацию через ЕСИА и зарегистрировать нового потребителя машиночитаемых данных. Для юридического лица ЕИС отдельно требует использовать подтвержденную учетную запись руководителя организации в ЕСИА.
Во время регистрации заполняются сведения о пользователе или организации, включая цель получения машиночитаемых данных, контактную информацию и другие регистрационные поля. Для юридического лица после этого нужно подписать и разместить печатную форму. Этот шаг часто забывают, а без него регистрация остается незавершенной.
Дальше сценарии расходятся. Физическое лицо и ВСРЗ переходят на вкладку получения токена. Юридическое лицо открывает вкладку получения доступа к сведениям и загружает сертификат, которым будут подписываться или аутентифицироваться запросы к сервису. В инструкции ЕИС указано, что для юридического лица можно использовать сертификат руководителя, обезличенный сертификат организации с ОГРН или сертификат физического лица со СНИЛС, если именно им будут направляться запросы.
Если говорить совсем просто, то после регистрации у вас должно получиться одно из трех состояний: либо у вас есть токен физлица, либо у вас есть настроенный сертификат юрлица, либо у вас есть пара токенов для сценария внешней системы. Без этого к сервисам ЕИС перейти нельзя.
Какой сервис выбирать
Для физического лица используется endpoint getDocsIP. Для юридического лица — getDocsLE. Для внешних систем размещения заказов — getDocsOrganization. В инструкции ЕИС прямо указаны эти три адреса и отдельно сказано, что в ответ на запрос приходит ссылка на архив с запрашиваемыми сведениями.
Здесь есть одна тонкость. В основной части инструкции уже приведены актуальные сервисы на новых доменах, но в технических приложениях по настройке stunnel еще встречается старый адрес int44.zakupki.gov.ru. Это не значит, что старая схема актуальна. Это значит, что технические приложения частично отстают от изменений доменной схемы, и при настройке интеграции нужно ориентироваться на официальные объявления ЕИС о новых доменах и на актуальные адреса сервисов в основной части документации.
Как устроен обмен с ЕИС
Многим кажется, что ЕИС должна отдавать готовый JSON по REST-запросу. Сейчас это не так. ЕИС работает через SOAP-сообщения. Пользователь отправляет SOAP-запрос, в котором указывает, что именно он хочет получить, а в ответ получает не саму карточку закупки, а ссылку archiveUrl на архив с данными. После этого выполняется отдельный GET-запрос на скачивание архива. Именно так этот процесс описан в инструкции ЕИС и для юридических лиц, и для физических лиц, и для внешних систем.
Сервис поддерживает несколько базовых типов запросов. getDocsByReestrNumberRequest позволяет получить документы по конкретному реестровому номеру. getDocsByOrgRegionRequest — получить документы по региону заказчика, типу подсистемы и дате. getDocsOrgRequest используется во внешних системах для выборки по набору параметров и организации-владельцу. getNsiRequest нужен для выгрузки справочников НСИ. Есть и отдельный запрос для подписей документов — getDocSignaturesByUrlRequest.
Важно понимать ограничения. В инструкции прямо сказано, что количество запросов в час ограничено, архив формируется асинхронно, за один запрос можно получить только один справочник или данные только по одной подсистеме, а в региональном запросе указывается только один тип документа. Это означает, что сервис нельзя использовать как безлимитный онлайн-источник для интерактивных аналитических запросов. Его нужно использовать как источник для собственной регулярной загрузки данных.
Какие запросы обычно нужны в реальной работе
Самый простой стартовый запрос — получение документа по реестровому номеру. Это лучший способ проверить, что регистрация, сертификат или токен, транспорт и структура SOAP-запроса настроены правильно. В инструкции именно этот сценарий показан первым и для юридических, и для физических лиц, и для ВСРЗ.
После того как запрос по реестровому номеру заработал, для массовой загрузки обычно переходят к запросу по региону заказчика, типу документа и точной дате. Такой запрос удобен для ежедневной или почасовой синхронизации: можно забирать документы за конкретную дату, отдельно по нужной подсистеме и нужному типу документа. В примерах ЕИС видно, что один такой запрос может вернуть сразу несколько archiveUrl, если выборка получилась большой.
Отдельно стоит подключить НСИ. Без справочников удобно жить только на самом первом этапе. Дальше почти всегда выясняется, что коды статусов, классификаторы, типы документов, виды процедур и другие значения лучше не хранить “как есть”, а связывать со справочниками. Для этого и существует getNsiRequest, а стартовая команда nsiAllList позволяет получить перечень доступных справочников.
Что в итоге приходит от ЕИС
На стороне разработчика важно правильно сформулировать ожидание: ЕИС отдает не “готовую витрину аналитики”, а документы. Сервис возвращает ссылку на архив, который потом скачивается отдельным запросом. Дальше эти документы нужно разбирать и собирать в свою модель данных. Именно поэтому почти все рабочие интеграции с ЕИС строятся вокруг собственного слоя преобразования данных, а не вокруг прямого обращения аналитики к ЕИС.
Для 44-ФЗ и 223-ФЗ наборы документов различаются по подсистемам. В инструкции ЕИС прямо перечислены типы документов для ряда подсистем 223-ФЗ: договоры, жалобы, планы закупок, извещения, протоколы, реестр недобросовестных поставщиков, отчетность и другие сущности. Для 44-ФЗ инструкция отсылает к актуальному Альбому ТФФ, где задаются коды subsystemType и верхние теги документов. Иными словами, реальный объект интеграции — не одна универсальная “закупка”, а набор документов ЕИС, из которых карточка закупки уже собирается в вашей системе.
Как правильно организовать хранение данных
Самая частая ошибка — пытаться каждый аналитический запрос обслуживать напрямую из ЕИС: сходить в сервис, скачать архив, разобрать его и тут же отдать результат пользователю. Технически это возможно, но практически это плохая стратегия. Она упирается в лимиты запросов, зависит от времени формирования архива и делает вашу аналитику зависимой от доступности внешнего контура именно в момент запроса.
Рабочая архитектура обычно состоит из трех слоев. Первый слой — raw-хранилище, где сохраняются исходные архивы и документы в том виде, в котором они пришли из ЕИС. Второй слой — нормализованные данные, где документы уже разобраны и разложены по удобной модели: закупки, лоты, заказчики, позиции, контракты, требования, вложения, справочники. Третий слой — витрины и аналитика, которые читают уже не XML и не архивы, а ваши внутренние таблицы. Такая схема позволяет перепарсить старые документы, если вы поменяли модель данных, и не дергать ЕИС повторно по уже полученным сведениям.
Если задача стоит просто и прагматично, оптимальный подход такой: ЕИС использовать как внешний источник сырых документов, а свою базу — как источник для поиска, отчетности, BI и API. Это делает систему и быстрее, и устойчивее.
Что нужно юридическому лицу на практике
Для юридического лица в актуальной инструкции ЕИС описан сертификатный сценарий. Это значит, что после регистрации одной записи или GUID недостаточно: сам доступ к getDocsLE строится через сертификат, загруженный в кабинете, и защищенное соединение. В приложениях к инструкции приведены примеры настройки для Windows Server и Linux через CryptoPro CSP и stunnel, где локальный HTTP-туннель используется для отправки XML в защищенный канал.
Это важный момент, потому что многие пытаются работать с юридическим лицом так же, как с физическим: вставить GUID в SOAP Header и ждать результата. Для getDocsLE это не тот сценарий. Если вы — юрлицо и хотите получить открытые данные ЕИС для своей системы, основной путь — загрузить сертификат, поднять защищенное соединение и отправлять SOAP-запросы уже через этот контур.
Когда нужен getDocsOrganization
getDocsOrganization нужен не всем. Это сценарий для внешних систем, которые получают документы конкретных организаций-владельцев. В инструкции ЕИС для него указаны два токена: self_registry_token и organization_token. Первый идентифицирует того, кто обращается к сервису, второй — организацию, документы которой нужно получить. Без обоих значений сценарий не считается полным.
Поэтому если у вас “на руках есть GUID”, этого еще недостаточно, чтобы автоматически считать себя подключенным к любому сервису ЕИС. Сначала нужно понять, к какому именно сценарию относится этот идентификатор: к физлицу, к ВСРЗ или к чему-то еще. Для юрлица, работающего по getDocsLE, ключевым объектом остается сертификат, а не GUID-токен в заголовке SOAP.
Типовой порядок запуска интеграции
Если нужна простая и рабочая последовательность без лишней теории, она выглядит так.
Сначала зарегистрируйтесь в ЕИС как получатель машиночитаемых данных. Затем определите свой сценарий доступа: физлицо, юрлицо или внешняя система. После этого настройте аутентификацию: токен для getDocsIP, сертификат для getDocsLE или пару токенов для getDocsOrganization. Дальше не начинайте с массовой выгрузки: сначала выполните один запрос по реестровому номеру и убедитесь, что получаете archiveUrl. Затем скачайте архив по GET-запросу, распакуйте его, разберите документы и только после этого переходите к регулярной загрузке по дате, региону и типу документа. Отдельным потоком заберите НСИ.
Именно такой путь лучше всего подходит для первой рабочей интеграции: он позволяет быстро отделить организационные проблемы доступа от технических проблем с транспортом и структурой запросов.
Частые ошибки
Первая ошибка — использовать старые домены из старых примеров и форумов. После летних изменений 2025 года это уже нерабочий путь. Нужно смотреть актуальные домены, а не ориентироваться на исторические snippets из старых статей и обсуждений.
Вторая ошибка — ожидать, что ЕИС сразу отдаст готовый JSON или “карточку закупки”. Сервис сначала отдает ссылку на архив, а уже потом пользователь скачивает архив и разбирает документы.
Третья ошибка — путать сценарии. Для физического лица нужен токен. Для юридического лица нужен сертификатный доступ. Для внешних систем нужны два токена. Когда эти сценарии смешиваются, интеграция либо не работает вовсе, либо работает нестабильно и непредсказуемо.
Четвертая ошибка — пытаться строить аналитику напрямую на запросах к ЕИС. При ограничениях по частоте запросов и асинхронном формировании архивов это рано или поздно приводит к проблемам с производительностью и воспроизводимостью результатов. Гораздо надежнее однажды забрать документы, сохранить их у себя и уже потом работать на собственном хранилище.
Итог
Получать данные из ЕИС сегодня можно, но это уже не история про “свободный FTP с XML-архивами”, а история про регламентированный сервисный доступ. Нужно зарегистрироваться, выбрать правильный сценарий доступа, использовать актуальные домены, уметь отправлять SOAP-запросы и понимать, что сервис возвращает не готовую аналитику, а документы, из которых эту аналитику еще предстоит собрать.
Если подойти к этому как к обычной инженерной задаче — с отдельным слоем raw-данных, нормализацией и собственной моделью хранения, — интеграция с ЕИС получается вполне рабочей и предсказуемой. Самое важное — не начинать с попытки “сразу скачать все”, а сначала пройти короткий путь: регистрация, один тестовый запрос, один скачанный архив, один успешно разобранный документ. После этого все остальное уже сводится к систематизации и масштабу.