ЕАИСТО интеграция и API ЕАИСТО-М

EAISTO.helper — как работать с ЕАИСТО из WEB-DK и ПТО

EAISTO.helper — бесплатное расширение для браузеров на движке Chromium (Chrome, Chromium GOST, Яндекс Браузер и аналоги). Оно связывает вашу учётную систему с ЕАИСТО-М: переносит данные карты из программы ПТО или кабинета WEB-DK на сайт ЕАИСТО и возвращает готовую карту обратно в учётную программу или кабинет. Отдельную Windows-программу «коннектор» ставить не нужно. Сценарии: если вы впервые на WEB-DK, с фото, с кабинетом или с 1С ПТО. Как это выглядит на экране — в ролике ниже.

Разработчики ЕАИСТО рекомендуют Chromium, но на практике сайт ЕАИСТО-М сегодня стабильно работает и в Яндекс Браузере — многие пункты оформляют карты именно в нём. Helper ставится из Chrome Web Store и в Яндекс Браузере тоже (раздел расширений / установка из магазина Chrome).

Что умеет расширение

• Перенести данные из учёта в ЕАИСТО. Карту готовите в своей программе или в WEB-DK, копируете данные, открываете ЕАИСТО-М и нажимаете Ctrl+Shift+Y — поля на сайте ЕАИСТО заполняются из вашей учётной системы, без ручного набора.
• Вернуть готовую карту в учёт. После регистрации в ЕАИСТО расширение передаёт PDF, номер карты и срок действия обратно в программу ПТО или кабинет WEB-DK — карта в учёте отмечается как оформленная.
• Фото с телефона. Снимки удобно делать в приложении «Фото для техосмотра» — на компьютер их можно передать несколькими способами (облако, почта, локальная сеть и др.). Один из вариантов — WEB-DK.Sync, когда обычный интернет ограничен. Фото участвуют в оформлении вместе с данными из учёта.

Сколько это стоит

Установка и обновление расширения — бесплатно. Платите только за действия, которые реально выполняете при оформлении карты: например, отправка черновика в ЕАИСТО, капча и связанные шаги — сумма списывается с лицевого счёта в личном кабинете WEB-DK (обычно несколько рублей за операцию). Пополнить счёт можно в кабинете, когда понадобится.

Как установить

Рекомендуемый способ — установить из Chrome Web Store (или кнопка «Chrome Web Store» в личном кабинете WEB-DK). Так расширение получает обновления автоматически.

Лучше всегда ставить из магазина: при ручной установке из ZIP автообновления не работают — новую версию нужно скачивать и подключать вручную. ZIP с сайта нужен только если в Chrome Web Store долго появляется обновление, а вам уже нужна свежая сборка.

Для ежедневной работы пункта с WEB-DK и программой ПТО этого достаточно. Если нужна полная автоматизация (госпошлина, подпись, очередь карт без ручной работы на сайте ЕАИСТО) — смотрите раздел про EAISTO Client Agent ниже или напишите нам; старую программу EAISTO.connector больше не поддерживаем.

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

EAISTO Client Agent — полная автоматизация

EAISTO Client Agent — программа на компьютере пункта для полной автоматизации работы с ЕАИСТО-М: от передачи данных карты (в том числе сведений о госпошлине и её проверки) до электронной подписи и получения готовой карты с PDF. Без ручного заполнения сайта ЕАИСТО. Подпись — через КриптоПро на ПК агента. Закрытый бета-тест: скачивание и доступ открываем по заявке — запросите доступ в личном кабинете.

Два режима работы

1. API-мост к ЕАИСТО. Стороннее приложение (1С, программа ПТО, ЛК WEB-DK в браузере) вызывает локальный HTTP API агента — агент сам логинится в ЕАИСТО, решает капчу, подписывает и возвращает результат. Ниже — актуальный контракт этого режима.
2. Очередь WEB-DK (portal queue). Агент сам забирает готовые карты из https://web-dk.ru/api/v7/dk/, проводит P1 → интервал → P2 → подпись и возвращает номер/PDF в кабинет — без кликов оператора на каждом шаге.

После установки укажите в агенте API-ключ из личного кабинета web-dk.ru и запустите сервис. Базовый адрес локального API: http://127.0.0.1:8080/api/v7/ (порт можно изменить). Авторизация — query-параметр access-token (тот же ключ, что в кабинете).

Актуальный префикс — /api/v7/. Кабинет WEB-DK выгружает карту именно так. Для совместимости со старыми клиентами 1С агент также отвечает на /api/ и /api5/ecp1c/ (send/sign). Устаревший параметр accesstoken (без дефиса) может приниматься, но в новых интеграциях используйте только access-token. Версию агента смотрите в ответе GET /api/status — в доке номер сборки не фиксируем.

Типовой порядок (API-мост, v7)

1. status — проверка, что агент запущен.
2. captcha с autoCaptcha=1 и certThumbprint — перед каждым шагом: вход в ЕАИСТО и решение капчи внутри агента.
3. create — черновик без фото. Два вызова с одним телом: первый возвращает next=create и retryAfter, id ещё нет; второй создаёт карту и возвращает id.
4. photo1 — тоже два вызова. Первый фото не загружает. Второй с image1 отправляет фото, записывает поля карточки и начинает интервал.
5. gp — проверка госпошлины. Если в ответе next равен gp-status, вызовите POST /api/v7/gp-status с тем же id.
6. Ожидание минимального интервала между фото.
7. photo2 — второе фото по id черновика. Если интервал ещё не прошёл, агент отвечает wait и retryAfter.
8. sign — подпись через КриптоПро в агенте.
9. print — номер карты и PDF, если их ещё нет в ответе sign.

Фото готовьте в «Фото для техосмотра» — на ПК любым удобным способом (облако, почта, локальная сеть; WEB-DK.Sync — если интернет ограничен). В ЛК WEB-DK «Выгрузить в ЕАИСТО» идёт шагами create (черновик и данные ТС, без фото) и photo1 (первое фото, затем повторное сохранение карты). Второе фото можно прикрепить после выгрузки, до конца диагностики. Завершение — шаги photo2 / sign / print. Кнопка «Завершить в ЕАИСТО» — запасной повтор, если вкладку закрыли в середине. «Прервать» после подтверждения вызывает POST /api/v7/cancel-active и снимает привязку черновика в кабинете: карту можно выгрузить заново.

Общие query-параметры локального API

• access-token — API-ключ из кабинета (обязателен для captcha / create / photo1 / gp / photo2 / sign / print / cancel-active).
• autoCaptcha=1 — агент сам решает капчу; клиенту не нужно показывать картинку и слать код вручную.
• certThumbprint — отпечаток сертификата эксперта (КриптоПро); агент выбирает нужный сертификат для подписи.
• iddk — опционально, id карты во внешней системе (в WEB-DK — id диагностической карты); помогает сопоставлять черновик.
• id — id черновика ЕАИСТО; обязателен начиная с photo1.

Методы локального API (режим моста)

{
  "diagnosticStart": "2026-07-30T14:10:00",
  "diagnosticFinish": "2026-07-30T14:45:00",
  "toOperator": "краткое имя оператора",
  "expert": "Иванов Иван Иванович",
  "expertForConnector": "",
  "expertTelegramCode": "",
  "eaistoId": null,
  "ExtSystem": "WEBDK",
  "ExtSystemID": "12345",
  "card": {
    "VehicleCategory2": "M1",
    "VehicleCategory": "B",
    "Vin": "VIN",
    "RegistrationNumber": "А123ВС777",
    "Year": "2018",
    "Killometrage": "120000",
    "EmptyMass": "1200",
    "MaxMass": "1800",
    "Tyres": "модель шин",
    "Fuel": "Petrol",
    "BrakingSystem": "Hydraulic",
    "diagnosticType": "первичная",
    "comment": "",
    "transportTypeName": "Легковые автомобили",
    "Vehicle": { "Make": "марка", "Model": "модель" },
    "RegistrationDocument": {
      "DocumentType": "RegTalon",
      "Series": "серия",
      "Number": "номер",
      "Organization": "кем выдан",
      "Date": "2020-01-15",
      "Foreign": "N"
    },
    "Tachograph": { "Brand": "", "Model": "", "SerialNumber": "" },
    "gbo": {
      "hasGasEquipment": false,
      "noGasBottle": false,
      "gasBottles": []
    },
    "paymentInfo": {
      "paymentId": "УИН госпошлины",
      "paymentDate": "2026-07-30",
      "preferentialInn": "",
      "preferentialKpp": ""
    },
    "diagnosticResults": [
      {
        "number": "1",
        "failed": false,
        "result": "Соответствует"
      }
    ]
  }
}

Очередь WEB-DK (portal queue)

Базовый URL: https://web-dk.ru/api/v7/dk/. Auth: query access-token. Нужна ветка portal_queue (GET /api/v7/dk/access; не путать с connector_api / галкой Client Agent).

Типовой цикл агента:

1. GET orders?status=READY — FIFO-очередь готовых карт.
2. POST claim — захват карты (agentId, certThumbprint).
3. GET order с photoFormat=base64 — получить ptoPayload для локального /api/v7/create и следующих шагов.
4. Локально: captcha → create → photo1 → gp → ожидание интервала → photo2 → sign → print.
5. POST status — промежуточные статусы (EAISTO_SEND_P1, WAITING_INTERVAL, …).
6. POST complete — номер, PDF, срок; либо POST release при ошибке.

Карта попадает в READY при заполненных эксперте, фото и УИН госпошлины. Payload для агента — схема eaisto-connector-1.0 (тот же JSON, что в API-мосте выше). Полный контракт методов, ошибок и recovery — во внутренней спецификации для разработчиков агента; интеграторам 1С обычно достаточно локального API-моста.

Своя программа пункта

Локальный API агента на компьютере эксперта — тот же путь, что у программы «Пункт технического осмотра». Своя CRM вызывает http://127.0.0.1:8080/api/v7/. Данные автомобиля и снимки из приложения «Фото для техосмотра» читаются с https://web-dk.ru тем же API-ключом. Очередь и приоритет заданий остаются в CRM. Агент выполняет один вызов и возвращает ответ. Второй запрос, пришедший раньше, ждёт в очереди, пока закончится текущий. Сменить приоритет ожидающего запроса нельзя.

Черновик, первое фото и правки

На POST /api/v7/create агент сам собирает черновик ЕАИСТО. Из JSON на этом шаге берётся категория VehicleCategory2 (если поля нет, подставляется M1) и diagnosticType (если поля нет — первичная). Имя эксперта, номер и адрес пункта агент берёт из сессии сертификата, не из полей expert и toOperator. VIN, госномер, документы, пробег, массы и diagnosticResults в запрос создания карты не отправляются. Пустые значения на create ЕАИСТО не проверяет: отдельного отказа «не хватает VIN» на этом шаге нет.

create — два вызова с одним и тем же телом. Первый возвращает next=create и retryAfter (обычно 3–8 секунд), id ещё нет: карту агент в этот момент не создаёт. После паузы второй create создаёт карту и возвращает id, next=photo1 и следующую паузу (обычно 20–40 секунд).

{
  "formatVersion": "eaisto-connector-1.0",
  "eaistoId": "0",
  "card": {
    "VehicleCategory2": "M1",
    "VehicleCategory": "B",
    "diagnosticType": "первичная"
  }
}

Интервал начинается, когда ЕАИСТО приняла первое фото, и не зависит от того, заполнены ли остальные сведения. У photo1 тоже два вызова. Первый, сразу после create, фото не грузит: в ответе next=photo1 и retryAfter обычно 70–100 секунд. Второй вызов с тем же id, полем image1 и JSON карточки загружает фото и записывает поля. Интервал идёт от этого второго вызова. Для M1 ориентир до второго фото — 30 минут, для N1 — 32. Точный остаток приходит в тексте ЕАИСТО, если photo2 вызван раньше срока.

Поля записываются на том photo1, который загружает фото. В ЕАИСТО в этот момент уходят VIN, госномер, категория, марка, модель, год, документ, пробег, массы, шины, топливо, тормоза и непройденные пункты diagnosticResults. id остаётся тем же. Если к этому моменту поля ещё пустые, в карту уходят пустые значения, и отказ ЕАИСТО придёт уже с этого photo1 или со следующего шага. Полный JSON, включая пробег, нужен на загружающем photo1.

Отдельного метода «обновить поля» нет. Если после принятого фото нужно исправить карточку, ещё раз вызовите photo1 с тем же id, актуальным JSON и снова с image1 в form-теле. Фото повторно не отправляется, если оно уже принято: агент перезаписывает поля. Пробег меняется этим повторным photo1. Интервал при такой правке не обнуляется, cancel-active не нужен.

• gp перезаписывает те же поля только когда в JSON есть госпошлина (УПНО или льгота). Пробег этот шаг не меняет. Если госпошлины в JSON нет, поля автомобиля gp не сохраняет. Уже идущую проверку (gpBindState=IN_PROCESS) новым gp не запускайте: дальше gp-status.
• gp-status только спрашивает состояние платежа.
• photo2 загружает второе фото и поля автомобиля не переписывает.
• sign подписывает карту, которая уже лежит в ЕАИСТО. Тело JSON на этом шаге агент не читает.
• print забирает PDF и номер по id.

Новый create заводит другую карту. id храните у себя. Пока у эксперта открыт черновик, новый create лучше не вызывать: агент продолжит уже открытый черновик или вернёт конфликт и вторую карту не заведёт.

Смену M1 → N1 текущая версия на том же черновике не проводит. Категория в JSON на photo1 запишется, но тип транспортного средства выбирается один раз при create и при правке не пересчитывается. Рабочий путь: POST /api/v7/cancel-active с этим id, затем новый create уже с N1. Первое фото и интервал начинаются заново. VehicleCategory у M1 и N1 один — B. Меняются VehicleCategory2 и заново собранный diagnosticResults: их кладут в JSON нового create и его загружающего photo1. Подписанную карту отменить нельзя.

В JSON агента эти поля такие:

• VehicleCategory2 — M1, N1, N2, N3, M2, M3, O1–O4, L. VehicleCategory — A для L, B для M1 и N1, C для N2 и N3, D для M2 и M3, E для O1–O4.
• Fuel — Petrol, Diesel, PressureGas, LiquefiedGas, PetrolLiquefiedGas, None. Для категории E поле пустое.
• BrakingSystem — Mechanical, Hydraulic, Pneumatic, Combined.
• RegistrationDocument.DocumentType — RegTalon (СРТС), PTS, EPTS.
• diagnosticType — первичная или повторная.

Ошибки проверки

При отказе в ответе error: true, message и id черновика, если он уже известен. Отдельного кода ошибки ЕАИСТО, имени поля и номера этапа нет. Какой шаг отказал, определяет адрес, который вы вызвали. HTTP-статус при таком отказе — 200. Если ЕАИСТО прислала собственную фразу, в message будет она. Проверка пробега выполняется на gp, если в JSON пробег больше нуля. Пример, когда ЕАИСТО не прислала свой текст:

{
  "error": true,
  "message": "В поле «Пробег ТС (км)» указан меньший пробег, чем в предыдущей диагностической карте данного транспортного средства. Дальнейшее создание ДК невозможно.",
  "captcha": "NONE",
  "id": "57501241"
}

Ответ wait: true и retryAfter — пауза, не отказ данных. Раннее второе фото тоже так: в message текст ЕАИСТО про «раньше срока» и «осталось N мин», поля error нет, next остаётся photo2. Капча посреди шага: error: true и в captcha картинка base64. Повторяется тот же шаг, не новый create.

Правка пробега, VIN, документов и госпошлины после уже принятого photo1 — повторный photo1 с тем же id, исправленным JSON и полем image1. Первое фото заново не загружается. Другой УПНО или льготу можно передать на gp с тем же id, пока проверка платежа не в состоянии IN_PROCESS. Пробег через gp не перезаписывается. Смена категории M1 → N1 — через cancel-active и новый create, как выше. Если не прошёл сам create и id нет, исправленный JSON отправляется новым create.

Фразы, которые формирует сам агент:

Любая другая фраза в message — текст ЕАИСТО как есть. Показывайте её эксперту. Полного перечня всех фраз ЕАИСТО нет.

Сбой ЕАИСТО и своя очередь

Окна «технический сбой» (время сбоя, начало и окончание, данные акта) в локальном API нет. Таких полей в JSON агент не принимает и отдельного метода для них нет. При подписи агент спрашивает у ЕАИСТО, действует ли сейчас такое окно, и этот ответ наружу не отдаёт.

После таймаута или ошибки храните последний успешный id и имя шага, который не завершился. Когда ЕАИСТО снова отвечает, вызовите captcha и повторите этот шаг с тем же id и актуальным JSON. Успешные create и загружающий photo1 второй раз не вызывайте: повторный photo1 нужен, только если вы правите поля. Уже принятое первое фото при повторе не уходит заново. Если оборвался sign, снова вызовите sign с тем же id. Когда карта уже подписана, агент вернёт успех и next=print, вторую подпись не поставит. Если оборвался print, снова вызовите print: это загрузка PDF по тому же id. Отдельный запрос состояния перед повтором не нужен.

Метода «текущий этап оформления» в /api/v7/ нет. Состояние хранит ваша программа: последний успешный id и последний ответ (id, next, error, message). По id агент не возвращает имя незавершённого шага. Повтор шага с сохранённым id безопасен: принятое фото не дублируется, уже подписанная карта уходит в print. POST /api5/ecp1c/search ищет карту по номеру, VIN или госномеру и возвращает id, номер, срок и состояние госпошлины. Это поиск уже существующей карты, не лента этапов.

Несколько заданий с приоритетом агент не хранит. Второй запрос ждёт окончания первого и затем выполняется в порядке прихода. После перезапуска агента память процесса пустая: сессия эксперта и запомненный id пропадают, черновик в ЕАИСТО остаётся. Порядок: GET /api/status, затем GET /api/v7/captcha, затем незавершённый шаг с сохранённым id. Агент не обнуляет черновик в полночь и не задаёт срок в сутках. Карту можно продолжать тем же id, пока у этого эксперта в ЕАИСТО она числится активным черновиком. Один сертификат — один такой черновик. Когда активного черновика уже нет, а карта не подписана, тот же id продолжить нельзя. Подписанную карту продолжают через print.

После неполадки ЕАИСТО уже принятые фото остаются на черновике. Сессия эксперта живёт, пока запущен агент и вход не потерян. После перезапуска её поднимает новый captcha, фото из-за этого не сбрасываются. sign повторяется тем же методом. Проверка госпошлины в состоянии IN_PROCESS повторяется через gp-status, а не новым gp. Ранний photo2 — это wait и retryAfter, не потеря черновика.

Госномер, данные автомобиля и фото

Распознавание госномера с фотографии автомобиля работает в приложении «Фото для техосмотра», когда снимок уже загружен на web-dk.ru. В Client Agent нет метода «передайте JPEG — получите номер». Своя CRM забирает готовые снимки:

В каждой записи есть адрес полного JPEG (imageUrl или GET /api/v7/files/photo/{id}?format=base64). Поле plate — распознанный госномер, если распознавание для этой учётки уже включено (открыт Client Agent, стоит программа пункта или расширение EAISTO.helper). Иначе plate пустое. CRM сама опрашивает recent. Передача по FTP этот метод не вызывает.

Характеристики автомобиля — отдельный запрос автозаполнения, после того как номер уже известен:

Тот же адрес принимает POST с JSON. Достаточно одного из полей: vin, reg_number или документ (doc_type: 0 СРТС, 1 ПТС, 2 ЭПТС, плюс doc_series и doc_number). Поиск только по документу идёт по нашей базе. По VIN и по госномеру при промахе запрос уходит во внешний источник.

В data.vehicle приходят те поля, которые нашлись: vin, reg_number, kuzov, rama, make, model, year, ts_category, ts_type, mass, mass_max, fuel, braking_system, серия, номер, дата и кем выдан документ. data.source — local или external, data.query_type — VIN, GRZ или DOC, data.price — списание с баланса. При действующей подписке ИТС на программу пункта автозаполнение — 0 ₽. Пустое поле значит, что значения нет в ответе. Пробег, марка шин и результаты диагностики в этом ответе не приходят: пробег эксперт вводит сам. fuel и braking_system здесь текстом («Бензин», «Гидравлический»). В JSON агента их нужно переложить в значения Fuel и BrakingSystem из списка выше. ts_category кладётся в VehicleCategory2, ts_type — в VehicleCategory.

Практический порядок для одной линии: эксперт снимает автомобиль в «Фото для техосмотра» → программа читает files/recent и забирает JPEG → по plate вызывает vinbase/get → эксперт сверяет документы и вписывает пробег → программа собирает полный JSON → create (два вызова, пока не появится id) → photo1 (первый вызов — пауза, второй — фото и запись всех полей, с этого момента идёт интервал). Если пробег или VIN появились уже после принятого photo1, их записывает повторный photo1 с тем же id и с image1 в теле.

Доступ

Локальный API агента, автозаполнение и чтение фото вызываются из своей программы тем же API-ключом. Очередь https://web-dk.ru/api/v7/dk/ — другой режим: агент сам забирает карты, которые уже хранятся на web-dk.ru. Положить туда задание своей CRM и поменять приоритет нельзя.

Агент в закрытом бета-тесте. Отдельного учебного контура ЕАИСТО для сторонней программы нет: после заявки агент работает с боевой ЕАИСТО под сертификатом эксперта. Запросите доступ в личном кабинете. Контракт шагов, JSON, ошибок, фото и автозаполнения — на этой странице.

Вспомогательные методы