Описание методов API сервиса ЭДО.МИГ24

Авторизация
Базовый сценарий
Статусы пакета
Работа с документами
Работа с пакетами
Подписание документов КЭП
Проверка подписи документа
Списки контрагентов
Сотрудники
Сервисные функции
Очередь обмена сообщениями API
Очередь обмена сообщениями Rabbit
Сценарий многостороннего подписания
Шаблоны документов

Точки входа

Тестовая среда - https://test-edo.ntssoft.ru/ Продуктовая среда - https://edo.mig24.online/

Запрос вашего код авторизации АПИ - info@mig24.ru
Telegram поддержки https://t.me/NTSsupport

Тестовый Swagger https://test-edo.ntssoft.ru/api-docs
Продуктовый Swagger https://edo.mig24.online/api-docs

Авторизация

Для доступа к сервису необходимо указать следующий заголовок:
Authorization: Bearer <token>
Токен для авторизации однозначно связан с организацией - Абонентом ЭДО.МИГ24.
Для каждого Абонента необходимо получение своего токена.

Перед запросом доступа Абонент должен зарегистрироваться в сервисе.

Запросить token можно через info@mig24.ru или в Telegram https://t.me/NTSsupport
Предоставление доступа к тестовой среде - бесплатно на 30 дней.
Предоставление доступа к продуктовой среде осуществляется на платной основе. При окончании оплаченного срока (или тестового периода) доступа авторизация возвращает ошибку: "Оплаченный срок доступа истек".


Базовый сценарий работы

swagger

В сервисе используется понятия:
  • Документ - файл с данными
  • Пакет - набор файлов (копия Документа, его подпись, сопутствующие технологические квитанции, титулы и т.п. неразрывно связанные с документом)
  • Группа пакетов - набор Пакетов (по сути документов), имеющих общего отправителя и получателя, передающихся одновременно. Может состоять из одного пакета (документа).

Порядок работы:

Загружаем необходимые для отправки документы, указывая свой идентификатор (GUID) для каждого загружаемого файла:
  • неформализованный - /api/v1/documents/{DocumentId}/informal,
  • формализованный УПД (json) - /api/v1/documents/upd.
  • с авто определением типа - /api/v1/documents/{id}

После загрузки формализованного документа, сервис автоматически выполняет визуализацию этого документа в pdf-формате.
При успешном завершении визуализации формируется идентификатор {id} полученного файла визуализации (id) и передается в очередь сообщений /api/v1/events/completed-visualization.
При необходимости, запросить визуализацию черновика документа в формате pdf можно через /api/v1/documents/upd/draft-visualization/{id}.

Создаем группу пакетов методом - /api/v1/package-groups, указывая код абонента получателя документов recipientAbonentCode или, если код абонента не известен, заполняем блок recipientOrg (e-mail, название, ИНН, КПП, ОГРН получателя документов), при этом для каждого документа создается Пакет внутри Группы пакетов (т.е. любой документ всегда "завернут" в пакет и далее группу пакетов).
Для каждого документа проставляется отдельным параметром необходимость подписания его получателем.
При необходимости добавить пакеты в уже созданную группу это делается методом - /api/v1/package-groups/{id}/packages.

Подписываем документы:
  • Пользовательским сертификатом: Запрашиваем хеши документов пакета для подписания, передавая сертификат подписанта - /api/v2/signing-transactions/prepare, подписываем хеши на клиенте и завершаем подписание методом - /api/v1/signing-transactions/finish
  • Через отправку документа на подписание нужному сотруднику (для сотрудника предварительно через web интерфейс необходимо указать способ подписания по умолчанию (сертификатом в web, ГосКлюч, АП ЭДО, Приложение МИГ24) и при необходимости выбрать его МЧД)). Для этого используется метод /api/v1/signing-requests, в котором нужно указать идентификатор сотрудника, кто будет подписывать документы.
Идентификатор Сотрудника можно получить методом /api/v1/organization-users

После подписания документов в пакете, для которого был указан ID Абонента, Сервис проверит наличие связи (дружбы) с указанным Абонентом, и если ее нет - Сервис самостоятельно вышлет приглашение этому Абоненту. При наличии установленной связи, или когда Контрагент примет приглашение, сервис опять же самостоятельно отправит подготовленный документ получателю.

После подписания документов в пакете, для которых НЕ был указан ID Абонента, Сервис подготовит ссылку для подписания документов этого пакета Получателем и отправит ее на указанный e-mail получателя в виде письма-уведомления о необходимости подписать документ.
Получатель, пройдя по полученной ссылке сможет на выбор:
  • подписать документ КЭП уполномоченного лица
  • указать нужный (другой) ID Абонента в том сервисе ЭДО, который он использует
  • отказаться от подписания, указав причину и контактные данные для связи.
Сервис подготовит и передаст соответствующее выбранному действию контрагента сообщение в очередь сообщений.

Все статусы обработки документов автоматически передаются Сервисом в индивидуальные очереди сообщений. Так же в эту очередь передаются все факты принятия или отказа приглашений для обмена документами (дружба).

Статусы, которые может принимать пакет

swagger

Работа с документами

swagger

POST Загрузка документа с автоматическим определением типа - -/api/v1/documents/{id}
Id - guid документа, присваивается пользователем самостоятельно.
Используется для загрузки в сервис уже готовых xml.

POST Загрузка неформализованного документа -/api/v1/documents/{Id}/informal
Id - guid документа, присваивается пользователем самостоятельно

POST Создание формализованного Счета (json) - /api/v1/documents/payment-invoice
Схема документа (Markdown)

POST Создание формализованного УПД (json) - /api/v1/documents/upd
Схема json, пример

POST Создание формализованного документа Акт сверки (json) - /api/v1/documents/checking-payments-act
Схема документа (Markdown)

GET Получение списка документов, загруженных в сервис - /api/v1/documents
Для авторизовавшегося пользователя.
Возвращается массив сведений о документах: id, название, id файла подписи, дата создания.

GET Получение сведений о документе - /api/v1/documents/{id}

GET Получение документа из сервиса - /api/v1/documents/{id}/file

GET Получение визуализации черновика загруженного документа - /api/v1/documents/upd/draft-visualization/{id}
При загрузке УПД через API выполняется запрос по визуализации документа. При завершении запроса формируется Id, по которому можно скачать PDF файл. Id подготовленного файла присылается в очередь сообщений.

GET Метод возвращает список поддерживаемых неформализованных типов документов - /api/v1/documents/informal/types
По умолчанию все неформализованные типы имеют тип «Неформализованный» (Id = 0). Не все типы поддерживаются согласно РОСЭУ, поэтому для их передачи другим операторам используется тип «Неформализованный». Данный метод позволяет внешним интеграторам получить актуальный перечень доступных типов для корректной загрузки документов.

Возвращается массив объектов NonFormalizedTypeViewModel:
  • Name (string) — внутреннее наименование типа (системное имя).
  • NameLocal (string) — локализированное наименование типа (отображаемое пользователю).
  • Id (int) — идентификатор типа.
Пример ответа (JSON):
[ { "name": "Contract", "nameLocal": "Договор", "id": 3 }, { "name": "Act", "nameLocal": "Акт", "id": 2 } ]

Работа с пакетами документов

swagger

POST Создание группы пакетов документов -/api/v1/package-groups

POST Добавление пакетов в группе пакетов - /api/v1/package-groups/{id}/packages

PUT Обновить группу пакетов - /api/v1/package-groups/{id}

GET Получить список групп пакетов - /api/v1/package-groups

DELETE Удалить группу пакетов - /api/v1/package-groups/{id}

GET Получить информацию о группе пакетов - /api/v1/package-groups/{id}
Результат:
{ "id": "ea51ebce-c0e2-4ee5-9d59-65a45717c6c6", // Идентификатор PackageGroup
 "sender": { // Реквизиты отправителя
  "inn": "1234567891",
  "ogrn": "2222222222221",
  "kpp": "568643355",
  "name": "ООО \"Скверные моторы\""  
},
 "recipient": { // Реквизиты получателя
  "inn": "8857137300",
  "ogrn": "9255392446861",
  "kpp": "998721016",
  "name": "ООО \"Рога и Копыта\""
 },
 "creationDateTime": "2025-06-29T07:11:38.978152Z", // Дата создания
 "packages": [
  {
   "id": "f41d82a2-52ee-4bfc-9028-ee6addf5ef01", // Идентификатор Package
   "name": "УПД", // Наименование пакета
   "providerFileInfo": {
    "packageFileId": "96b4d139-45be-42c3-a400-6c053efc02cf", // Идентификатор PackageFile первичного документа
    "name": "ON_NSCHFDOPPR_2JF-ED5146DE-A98C-42F0-B803-6B971530A01E_XXX-
E13FB48B-7E73-4BC0-9650-38C0EA244D2A_20231212_34e852e9-2283-46ed-9969-d98904e19dac_0_0_0_0_0_00.xml",
    "number": "test_updsfaktdop", // Номер документа
    "date": "2025-06-29T07:11:38.978152Z", // Дата документа
    "formalizedDocType": "ProviderUTD" // Тип документа
   },
   "statusId": 4, // Номерной статус пакета
   "statusName": "Подписан", // Наименование статуса пакета
   "creationDateTime": "2025-06-29T07:11:38.978829Z", // Дата создания пакета
   "modificationDateTime": "2025-06-29T07:15:18.812369Z" // Дата модификации пакета
  }
 ]
}
GET Получить информацию о пакете - /api/v1/packages/{id}/info
Результат:
{
 "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
 "name": "Счет-Фактура", <- Именование документа/пакета 
 "providerDocumentNumber": "string",
 "providerDocumentDateTime": "2025-09-12T12:41:18.665Z",
 "sender": {
  "inn": "string",
  "ogrn": "string",
  "kpp": "string",
  "name": "string",
  "code": "string"
 },
 "recipient": {
  "inn": "string",
  "ogrn": "string",
  "kpp": "string",
  "name": "string",
  "code": "string"
 },
 "creationDateTime": "2025-09-12T12:41:18.665Z",
 "modificationDateTime": "2025-09-12T12:41:18.665Z",
 "statusId": 0,
 "status": "string",
 "statusName": "string",
 "packageFiles": [
  {
   "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
   "fileName": "string",
   "isWaitRecipientSignature": true,
   "isProviderFile": true,
   "isCustomerFile": true,
   "fileType": "Unknown",
   "contentType": "string",
   "formalizedDocType": "None",
   "nonFormalizedDocType": "NonFormalized",
   "serviceDocType": "None",
   "documentNumber": "string",
   "documentDateTime": "2025-09-12T12:41:18.665Z",
   "senderAbonentCode": "string",
   "recipientAbonentCode": "string"
  }
 ]
}
GET Скачать файлы пакета архивом - /api/v1/packages/{id}/files

GET Скачать выбранный файл из пакета - /api/v1/packages/{id}/files/{packageFileId}

GET Скачать первичный файл пакета - /api/v1/packages/{id}/provider-file

GET Запросить текущий статус пакета асинхронно - /api/v1/packages/{id}/status/async

Создание действий с пакетами
swagger

После создания пакета сервис автоматически определяет, какие действия (принять, отклонить, подписать, запросить уточнение, аннулировать и т.д.) доступны пользователю в зависимости от статуса пакета, типа документа и роли пользователя в документообороте.
GET Получение списка возможных действий с пакетом - /api/v1/packages/{id}/actions
Возвращает список возможных действий в виде json
Пример json:
{"packageId": "e569cb00-43c0-4070-8d13-80b867c60e0e",
"actions": [{"type": "AddSenderSign", - тип действия
"isAvailable": false - признак возможно ли действие },
{"type": "AddCancellation", "isAvailable": false }, {"type": "AddCancellationAccept", "isAvailable": false },
{ "type": "AddCancellationRefuse", "isAvailable": false} ]}
Перечень действий:

Действие - Сформировать Извещение о получении
Тип действия - AddReceiptNotice
POST /api/v1/packages/{id}/actions/receipt-notice

Действие - Сформировать Уведомление об уточнении
Тип действия - AddClarification
POST /api/v1/packages/{id}/actions/clarification

Действие - Сформировать 2-й титул формализованного документа
Тип действия - AddSecondTitle
POST /api/v1/packages/{id}/actions/second-title
Ограничения:
- Пока метод действия создает второй титул только с успешным исходом:
- УПД с кодом итога 1 - товары (работы, услуги, права) приняты без расхождений (претензий)
- УКД с содержанием операции - "С изменением стоимости согласен" и дата согласования (согласия) равной дате формирования файла
- Акт сверки взаимных расчётов с признаком наличия разногласий = 1 – нет разногласий между сверяемыми операциями отправителя и получателя

Действие - Сформировать 2-й титул УПД (устаревший метод)
Тип действия - AddSecondTitle
POST /api/v1/packages/{id}/actions/utd-second-title

Действие - Сформировать подпись получателя неформализованного документа
Тип действия - AddRecipientSign
POST /api/v1/packages/{id}/actions/recipient-sign

Действие - Сформировать Предложение об аннулировании
Тип действия - AddCancellation
POST /api/v1/packages/{id}/actions/cancellation-offer

Действие - Принять предложение об аннулировании (сформировать ответную подпись)
Тип действия - AddCancellationAccept
POST /api/v1/packages/{id}/actions/accept-cancellation

Действие - Отказать в предложении об аннулировании (сформировать УоУ)
Тип действия - AddCancellationRefuse
POST /api/v1/packages/{id}/actions/refuse-cancellation
Методы возвращают Json со следующим содержанием:
 {
 "packageActionId": "8188f66d-0329-4c7b-b285-4b817293b086", - Идентификатор действия
 "actionStatus": "SigningExpected", - Статус действия
 "signingRequests": [ - Запросы на подписание
  {    "id": "251bacb6-fb1c-49d2-ad11-4fc35e2824e9"   }  ] }
Действие - Подписать и отправить черновик
POST /api/v1/package-groups/{id}/actions/sign-and-send

Метод возвращаeт Json со следующим содержанием:
{
  "packageGroupActionId": "3fa85f64-5717-4562-b3fc-2c963f66afa6", // Идентификатор созданного действия
  "actionStatus": "Pending", -  статус действия
  "signingEntity": { - сущность требующая подписания
    "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "type": "PackageGroupAction"
  }
}

Подписание документов

swagger

- Внешняя система создает PackageAction.
- Если PackageAction имеет статус «SigningExpected», то документы действия нужно подписать.

Подготовка и отправка документов на подписание сотруднику, кому необходимо произвести подписание (по UserId сотрудника).
После выполнения метода сервис отправит документ на подписание указанному сотруднику в соответствии с предустановленному для него способу подписания (на форме, ссылка, АП ЭДО, приложение МИГ24, ГосКлюч и т.п.). При наличии настроенного выбора МЧД, данная доверенность будет применена при подписании.
Если для сотрудника не установлен вариант подписания по умолчанию вернется ошибка

POST /api/v1/signing-requests
"signingEntity": {
"id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", // Идентификатор сущности (либо PackageId, либо PackageGroupId)
"type": "Unknown" // Тип сущности (либо "PackageAction", либо "PackageGroupAction")
},
"targetOrgUserId": "3fa85f64-5717-4562-b3fc-2c963f66afa6" //userId сотрудника
}
Метод подписания документов универсальный, и для подписания может принимать разные сущности.
Список возможных сущностей на подписание:
PackageAction — Действие с пакетом, требующее подписание
PackageGroupAction — Действие с группой пакетов, требующих подписание.

Подписание документа с указанием сертификата КЭП, подписывающего сотрудника

Шаг1 POST /api/v2/signing-transactions/prepare - Метод получения hash документов, требующих подписания
{
"token": "string", // идентификатор сессии этого подписания
"certificate": "string", / сертификат КЭП подписанта в base64
"mchdInfoId": "3fa85f64-5717-4562-b3fc-2c963f66afa6", / идентификатор МЧД (не номер!!)
"signingEntity": {
"id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", / PackageActionId
"type": "PackageAction"
} }
Шаг2 POST /api/v1/signing-transactions/finish - Финальный метод подписания, подписать полученные хэши и отправить в метод
{
"token": "string", // идентификатор сессии этого подписания
"files": [
{
"fileId": "3fa85f64-5717-4562-b3fc-2c963f66afa6", / идентификатор файла
"signature": "string" // подпись хеша 
} ] }
Подписание выполнено!

Архивный способ подписания документов:
Предоставление сертификата КЭП подписанта, запрос хеша документов для подписания
Шаг 1 POST /api/v1/sign/package-group/prepare
Подписание полученного хеша документов на стороне внешней ИС, отправка подписей хешей в сервис, завершение формирования подписей документов
Шаг 2 POST /api/v1/sign/package-group/finish

POST Подписать группу пакетов серверным сертификатом по идентификатору сотрудника - /api/v1/sign/package-group/user
Указывается идентификатор сотрудника

Проверка подписи документа

swagger

При получении сервисов подписи документа (хоть входящего, хоть исходящего) автоматически запускается ее проверка. По итогу проверки формируется событие в очередь "Завершение проверки подписи документа - GET /api/v1/events/signature-validation-completed"
Для каждого события передается:
"EventId": Идентификатор события
"Id": Идентификатор проверки
"PackageId": Идентификатор Пакета
"PackageFileId": Идентификатор подписанного документа
"PackageSignatureId": Идентификатор файла подписи
"CreationDateTime": дата время проведения проверки
"ModificationDateTime": Дата время изменения проверки
"Status": код статуса проверки 
"StatusString": текст статуса проверки
(3 -Проверка пройдена, подпись валидна, 4 - Проверка пройдена, подпись невалидна, 5 - Проверка не пройдена, возникли ошибки при проверке)
GET Получение расширенных результатов проверки подписи - /api/v1/validation/{id}
Возвращается общий статус проверки, информация о подписанте, а также результат проведения 13 возможных проверок.

POST Создание новой проверки подписи документа - /api/v1/validation
"packageId": Идентификатор пакета,
"packageFileId": Идентификатор документа в пакете
"isSender": true/false - запросить подпись отправителя или получателя
GET Получение списка проверок для пакета - /api/v1/validation/packages/{packageId}

GET Получение списка полномочий из МЧД - /api/v1/mchd/powers - синхронный запрос для МЧД, уже полученных в сервис МЧД.МИГ24
Параметры principalInn и representativeInn проходят валидацию по маске ИНН. ИНН должен содержать 10 (для юридических лиц) или 12 (для физических лиц) цифр. Рекомендуется указывать только цифровые символы.
Пример запроса: GET /api/v1/mchd/powers?mchdNumber=00000000-0000-0000-0000-000000000000&principalInn=0000000000&representativeInn=000000000000
POST Создание запроса на получение полномочий из МЧД - /api/v1/mchd/powers/async
Модель с данными запроса. Id присваивается внешней системой, реквизиты проверяются на соответствие ИНН
Ответ возвращается в очередь  /api/v1/events/request-mchd-data
{
  "providerInn": "string",
  "representativeInn": "string",
  "number": "string",
  "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
}

Списки контрагентов и приглашения

swagger

Для того, чтобы можно было обмениваться документами, необходимо обменяться приглашениями
Для этого сторонами высылаются приглашения, которые могут быть в сервисе в разных статусах:
New - приглашение сформировано, не отправлено/ Sent - приглашение отправлено / Delivered - приглашение доставлено / Accepted - приглашение принято / Rejected - приглашение отклонено.

POST Отправить приглашение к ЭДО - /api/v1/counteragent-requests
Отправляются Идентификатор ЭДО, ИНН/КПП/ОГРН/Название/email получателя приглашения, внутреннее примечание, комментарий для получателя.

POST Принять входящее приглашение - /api/v1/counteragent-requests/inbox/{requestId:guid}/accept
Указывается requestId сообщения с приглашением

POST Отклонить входящее приглашение - /api/v1/counteragent-requests/inbox/{requestId:guid}/reject 
Указывается requestId сообщения с приглашением и необязательная причина отклонения

POST Отозвать исходящее приглашение - /api/v1/counteragent-requests/inbox/{requestId:guid}/revoke
Указывается requestId сообщения с приглашением и необязательная причина отзыва

DELETE Удалить контрагента (разорвать существующую связь между организациями) - разорвать связь с КА
Указывается идентификатор записи контрагента (см. список контрагентов /api/v1/counteragents).

GET Получить все входящие приглашения - /api/v1/counteragent-requests/inbox
Ответом является массив данных, содержащих информацию из приглашений: Id Абонента, название, ИНН, КПП сторон, комментарии, статус и его дата.

GET Получить все исходящие приглашения - /api/v1/counteragent-requests/outbox
Ответом является массив данных, содержащих информацию из приглашений: Id Абонента, название, ИНН, КПП сторон, комментарии, статус и его дата.

GET Получить список контрагентов, для которых установлен обмен - /api/v1/counteragents
Ответом является массив данных, содержащих список контрагентов, с которыми успешно завершен обмен приглашениями (ID Абонента, название, ИНН, КПП, дата, idКонтрагента в сервисе)

Получение события успешного добавления контрагента (успешный обмен приглашениями) и отказа принять приглашение (или разрыв существующей связи) осуществляется через сервис очередей или сервис очередей RabbitMQ


Сотрудники

swagger

GET Получить информацию о сотрудниках организации -/api/v1/organization-users
    {
      "id": "9a57cbf8-0с1e-4676-b3bf-a081d5903190", // id сотрудника
      "orgId": "5c782e6c-8e50-4a6f-a5bd-b8fd47dad1a6", // id организации сотрудника
      "userId": "00000000-0000-0000-0000-000000000000",
      "accessId": "00000000-0000-0000-0000-000000000000",
      "name": "Иванова Екатерина Викторовна", // ФИО сотрудника
      "mchdInfoId": "9e1cd998-4adc-4fc3-bbf1-9eb340e4c734" // идентификатор МЧД
    }
GET Получить сведения по сотруднику - /api/v1/organization-users/{userId}
{
  "id": "00000000-0000-0000-0000-000000000000",
  "userId": "00000000-0000-0000-0000-000000000000",
  "name": "Иванова Екатерина Викторовна",
  "snils": "15327365141",
  "inn": "664801945637",
  "organizationId": "00000000-0000-0000-0000-000000000000",
  "isAdmin": false,
  "status": "Employee",
  "email": "ekaterina@yandex.ru",
  "canCreateDocs": false,
  "canDeleteAndRestoreDocs": false,
  "canSignDocs": false,
  "canAgreeDocs": false,
  "canSignDocsByAnotherUser": false,
  "canEditContractors": false,
  "mchdInfoId": "00000000-0000-0000-0000-000000000000",
  "position": "Руководитель отдела",
  "hasAccessMig24": true,
  "hasAccessEdo": true,
  "hasAccessMchd": true,
  "birthDate": "1997-09-01T00:00:00",
  "citizenship": "RussianFederationCitizen",
  "gender": "Female",
  "residentialAddress": {},
  "isActive": true,
  "accesses": [
    "00000000-0000-0000-0000-000000000000",
    "00000000-0000-0000-0000-000000000000"
  ]
}
POST Создать нового сотрудника организации - /api/v1/organization-users
{
  "name": "string",
  "position": "string",
  "snils": "string",
  "inn": "string",
  "isAdmin": true,
  "employerContacts": {
    "email": "string",
    "phone": "string"
  },
  "userContacts": {
    "email": "string",
    "phone": "string"
  },
  "identityDocument": {
    "expDate": "2026-06-18T14:03:34.371Z",
    "documentTypeCode": "string",
    "seriesAndNumber": "string",
    "issueDate": "2026-06-18T14:03:34.371Z",
    "issuerName": "string",
    "issuerDepartmentCode": "string"
  },
  "personalInfo": {
    "birthDate": "2026-06-18T14:03:34.371Z",
    "birthPlace": "string",
    "gender": "None",
    "citizenship": "None",
    "residentialAddress": {
      "subjectCode": "string",
      "address": "string"
    },
    "countryCode": "string"
  },
  "mchdInfoId": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
}
POST Создать нового сотрудника организации по сертификату КЭП - /api/v1/organization-users/by-certificate
Необходимо передать сертификат КЭП сотрудника в Base64 и mchdinfoid
PUT Обновить данные сотрудника организации - /api/v1/organization-users/{id]
Данные о сотруднике. Ожидается полная модель, которая заменит текущую. Передаётся в Body в формате Json
GET Получить настройки подписания сотрудника - /api/v1/organization-users/{id}/signing-settings
{
  "id": "3fa85f45-5717-4562-b4fc-2c963f66afa6",
  "edmsAbonentUserId": "3fa45f64-5717-6562-b3fc-2c963f66afa6",
  "creationDateTime": "2026-06-18T14:12:14.965Z",
  "mchdInfoId": "3fa84f64-5717-4582-b3fc-2c963f66afa6",
  "mchdType": "string",
  "canSignApi": true,
  "canSignByEmailLink": true,
  "email": "string",
  "canSignAPEdo": true,
  "tokenAPEdo": "3fa84f64-5717-4562-b5fc-2c963f66afa6",
  "canMigMobileSign": true,
  "migMobileUserSnils": "string",
  "canGosKeySign": true,
  "gosKeyUserSnils": "string",
  "goskeyExpiresSignInMinutes": 0,
  "defaultSignOption": "string"
}
PUT Обновить настройки подписания сотрудника - /api/v1/organization-users/{id]/signing-settings
Ожидается полная модель, которая заменит текущую. Передаётся в Body в формате Json

Сервисные функции

swagger

GET Получение информации об операторах ЭДО, с кем возможен обмен - /api/v1/operators
Массив сведений об операторах:
"code", "companyName", "productName", "inn", "kpp"

GET Получение данных Контрагента по коду Абонента - /api/v1/abonents/{code}/requisites
Если доступ к указанному коду открыт в ФНС, сервис вернет реквизиты данного Абонента

GET Получение списка известных ФНС кодов Абонента - /api/v1/abonents/by-requisites
По ИНН вернется список всех известных ФНС кодов Абонента у различных операторов ЭДО (для всех КПП этого ЮЛ), включая комментарии к коду, при их наличии, статус активности абонента (0 –неактивный, 1 – малоактивный, 2 – активный, 3 – новый) и перечень лиц, для которых зарегистрированы в ФНС их сертификаты КЭП (ФИО). При необходимости можно сузить запрос, указав дополнительно КПП.

GET Получение информации о привязанном к токену Абоненте - /api/v1/abonents/me
При успешном выполнении возвращает следующий JSON:
{
 "id": "527dc1fd-96c4-46f3-b73d-272a7aabc0bf", // Идентификатор абонента
 "orgId": "ed5146de-a98c-42f0-b803-6b971530a01e", // Идентификатор организации абонента
 "inn": "8857137300", // ИНН
 "ogrn": "9255392446861", // ОГРН
 "kpp": "998721016", // КПП
 "name": "ООО \"Рога и Копыта\"", // Наименование организации
 "code": "2JF-ED5146DE-A98C-42F0-B803-6B971530A01E" // Код абонента организации
 "payInfo": {
    "accessPeriodEnd": "2026-06-18T13:47:25.636Z",
    "compositDateTimeEnd": "2026-06-18T13:47:25.636Z",
    "packages": 0,
    "balance": 0,
    "compositPackages": 0,
    "compositBalance": 0
  }
}
POST Проверка кодов маркировки в ИС Честный знак - /api/v1/mark-product/check-codes
Принимает на вход массив кодов маркировки
Ответ:
[ {
"code": "01046363324553462151AhFPC", 
"found": true, //Признак наличия КМ в ГИС МТ 
"type": "Cis",
"groups": [ 15 ], 
"productGroupInfos": [ { "code": 15, "name": "beer", "description": "Пиво, напитки, изготавливаемые на основе пива, слабоалкогольные напитки" } ], 
"valid": true, 
"printView": "01046363324553462151AhFPC" //Структура КМ для передачи в ЭДО-документах 
}]
type:
• cis - код маркировки товара (групповой или обычный код идентификации);
• sscc - код идентификации транспортной упаковки;
• atk - агрегированный таможенный код.

productGroupInfos: человекочитаемое описание группы товаров

POST Подключение нового Абонента Интегратором - /integration-api/v1/tokens
Метод предназначен для создания новых Абонентов.
Возвращается код доступа (токен) к API от имени созданного Абонента.
Необходимо передать набор сведений:
{
"certificate": "string", // сертификат КЭП сотрудника Абонента, строка в base64
"organizationType": "string", Ul / Ip / Sz / Fl 
"kpp": "string", КПП для ЮЛ
"mchdNumber": "string" номер МЧД для регистрации Абонента не ЕИО
}

Регистрация Абонента

swagger

Сценарии регистрации:
  • Создается карточка, получается ссылка, Абонент открывает ссылку, производит подписание заявления.
  • Создается карточка, получается pdf, PDF показывается Абоненты, через API производится подписание.
  • Создается карточка, отправляется на подписание указанным способом.

POST Создание регистрации (карточки) Абонента - /api/v1/registration/abonent
{
  "type": "Unknown", // Тип организации Unknown, Ul, Fl, Ip, Sz
  "name": "string", // Наименование организации или ФИО
  "inn": "string",
  "kpp": "string",
  "ogrn": "string", // ОГРН или ОГРНИП
  "taxAuthorityCode": "string", //Код налогового органа (ИФНС)
  "address": "string", // Юридический адрес
  "postalAddress": "string", // Фактический (почтовый) адрес
  "email": "string",
  "phone": "string",
  "isAccessAllowedOtherOperators": true, // Разрешен ли доступ для обмена документами другим операторам ЭДО (настройки роуминга)
  "isIncomingInvitationOptional": true, // Требуется ли подтверждение входящих приглашений от контрагентов
  "comment": "string", // Комментарий к регистрации
  "certificateBase64": "string" // Файл сертификата КЭП в формате Base64 -  при загрузке сертификата, данные об Абоненте заполняются из этого сертификата.
}

Ответ: 
{
    "id": "1feb3f2a-27b8-42bf-b8ba-14c3b09c65e7",
    "registrationUrl": "http://edo.mig24.online/registration/1feb3f2a-27b8-42bf-b8ba-14c3b09c65e7/finish"
}
Открыв полученную ссылку, можно подписать карточку регистрации и на это завершить процесс.
Открытие ссылки потребует авторизации пользователя в сервисе.

GET Получение PDF регистрации Абонента - /api/v1/registration/{id}/print
Указывается ID карточки регистрации Абонента

POST Создание процесса подписании регистрации Абонента - /api/v1/registration/{id}/sign
{
  "snils": "string",
  "ogrn": "string",
  "goskeyInterval": 0, / время в минутах, отведенное на подписание в ГосКлюч - максимум 1440
  "mchdInfoId": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
}

Ответ
{
    "id": "eec620d2-7107-4b32-b393-91499ce97dbd", // ид сущности на подписание
    "type": "abonentApplication"
}

Для подписания КЭП на форме интегратора выполняем два шага:
POST Первый шаг подписания - /api/v2/signing-transactions/prepare
{
  "token": "string",
  "certificate": "string",
  "mchdInfoId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "signingEntity": {
    "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "type": "Unknown"
  }
}
POST Второй шаг подписания - /api/v1/signing-transactions/finish
{
  "token": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "files": [
    {
      "fileId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
      "signature": "string"
    }
  ]
}
POST Отправка запроса на подписание в Госключ - /api/v1/registration/signing-requests
(в /integration-api/v1/registration/{id}/sign не забываем указать значение goskeyInterval)
{
  "signingEntity": {
    "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",  // Id из ответа "/integration-api/v1/registration/{id}/sign"
    "type": "abonentApplication"
  },
  "signingTypes": [ Подписание по Email - ByEmailLink, Подписание через АП ЭДО - APEdo, Подписание через мобильное приложение МИГ24 - MigMobile, Подписание через приложение Госключ - GosKey, Подписание через приложение МояПодпись - MySign
  ]
}

Очередь обмена сообщениями API

swagger

Все сообщения, подготовленные сервисом для пользователя помещаются в соответствующие отдельные очереди событий.
Возвращается список последних (25 штук по умолчанию) событий
Тело ответа:
{ "meta": { "totalCount": 0, "currentPage": 2, "limit": 10 }, "data": [] }
В каждом событии есть уникальное поле eventId.

Метод POST /api/v1/events/<eventId>/ack подтверждает получение конкретного события.
Метод POST /api/v1/events/ack подтверждает получение списка событий.

После подтверждения получения событие не отображается в очереди.

Сервис поддерживает работу с очередями со смещением (offset)
Например, если несколько пользователей обращаются к одной очереди, данный метод решит возможную проблему, что кто-то уже забрал сообщение и пометил как полученное.

Для обращения к необходимой очереди, используя режим смещения, нужно добавить "/next",
например, новые контрагенты - GET /api/v1/events/counteragent-created/next
По умолчанию размер пачки - 25.
Также смещение можно указать при конкретном вызове, добавив в конце - ?offset=10&limit=100, где offset - смещение, а limit - размер пачки. При этом если в таком варианте будет прочитано данных больше, чем текущее смещение для очереди, то в смещение для очереди будет указаны новые данные. И при чтении без указания offset и limit будет продолжено с новой точки.

Метод POST /api/v1/events/{eventType}/reset обнуляет смещение для конкретной очереди.

Очередь обмена сообщениями Rabbit

Брокер сообщений — программное обеспечение и определённый архитектурный паттерн, который позволяет выстроить действия в информационных системах таким образом, чтобы обеспечить асинхронный обмен сообщениями между сервисами.

Асинхронный обмен предполагает отправку запроса или сообщения от одного сервиса к другому, при этом деятельность сервиса-отправителя не приостанавливается в ожидании ответа от получателя. Также обеспечивается надежная доставка, если произошла перезагрузка брокера или клиента, то сообщение никуда не пропадет и будет доставлено.

Мы используем RabbitMQ. Клиенты есть для всех популярных языков - https://www.rabbitmq.com/client-libraries/devtools

Подключение:
  • Сообщаете нам ip-адрес, с которого будете осуществлять работу.
  • Мы создаем пользователя (логин и пароль) и vhost. vhost - абстракция, где хранятся очереди и сообщения только для конкретного пользователя.
  • Выдаем Вам логин, пароль, vhost и адрес сервера. Очереди уже будут созданы и будут получать сообщения с событиями системы
  • Вы выбираете библиотеку для подключения, указывает хост, логин, пароль и vhost и название очереди, из которой должны считываться сообщения. Пример в документации (раздел Subscribe - https://www.rabbitmq.com/tutorials#3-publishsubscribe)

Сценарий многостороннего подписания
swagger

Сервис позволяет организовать процесс многостороннего подписания загруженного документа сотрудниками организаций - Абонентами ЭДО.МИГ24.
Блок методов в swagger- Mig24SharedFileApi

GET /api/v1/mig24/users - Запрос идентификатора подписанта как сотрудника необходимой организации или как физического лица. По СНИЛС предоставляется перечень организаций, в которых указанное лицо добавлено в сервисе ЭДО.МИГ24 как сотрудник.
Для каждой найденной записи возвращается:
Сведения о подписанте ("id": идентификатор, "name": ФИО, "snils": СНИСЛ, "inn": ИНН, "email":email, "phone": телефон) и сведения об организации "organization": { "id": идентификатор", "name": названия, "ogrn": ОГРН, "inn": ИНН, "kpp": КПП}

POST /api/v1/mig24/files/{id} - Загрузка необходимого файла на сервер.
Указывается идентификатор (guid)

POST /api/v1/mig24/shared-file Подготовка документа к подписанию.
Необходимо подготовить запрос:
"fileId": Идентификатор(ы) загруженного файла, который необходимо подписать, 
"targetSignatureType": формат подписи "Detached" открепленная,
"signerRequirements": - перечень подписантов {
"signerOrgUserId": идентификатор подписанта,
"notificationEmail": email подписанта -при указания данного параметра сервис отправит на указанный email уведомления о необходимости подписать документ } 
"signatureSettings": параметры подписи {
 "isBase64": true -подпись в pem формате, 
 "isOneLine": true - подпись в base64 в одну строку, 
 "cadesType": "CadesBes", "CadesT", "CadesXLongType1", "CadesA", 
 "extractFromZip": true - подписать все файлы в архиве, 
 "typeSigning": "Parallel" - (Sequential,Parallel) последовательное или параллельное подписание,
"isPaid": true - проставление признака оплаты подписания документа (необходимое для оплаты количество пакетов спишется с организации, инициатора подписания) 
 "organizationId": идентификатор организации-инициатора подписания
 "organizationUserId": идентификатор сотрудника организации- инициатора подписания.
После успешного выполнения метода возвращается набор параметров:
"registryInfoId": идентификатор документа (пакета), подготовленного к подписанию
"url": ссылка на страницу подписания.
Документ появляется в специальной папке (Персональные) в сервисе ЭДО у каждого из указанных подписантов с возможностью подписания этого документа в сервисе.

При необходимости подгрузить КЭП к загруженному для подписания файлу, созданную не в сервисе ЭДО.МИГ24 можно, предварительно загрузив файл подписи через POST /api/v1/mig24/files/{id}, использовать метод POST /api/v1/mig24/shared-file/append { "userFileInfos": [ { "sourceUserFileId": идентификатор подписанного файла, "userFileId": идентификатор файла загруженной подписи, "userFileType": DetachedSig - описание типа загруженного файла, "signerOrgUserId": идентификатор подписанта } ], "sharedFileId": идентификатор подготовленного для подписания файла (пакета)}
При добавлении подписи этим методом сервис проверит корректность этой подписи, действительность сертификата КЭП и при положительном результате присоединит эту подпись к документу в сервисе.

После каждого успешного получения подписи сервис формирует соответствующее событие в очередь подписания GET /api/v1/events/mig24-signature-completed
В событии можно получить
"EventId": идентификатор события, "SharedFileId": идентификатор подписанного документа, "SignatureUserFileId": идентификатор файла подписи, "SignerOrgUserId": идентификатор подписанта, "CreationDateTime": дата время подписания" },
После успешного получения информации о событии необходимо подтвердить получение методом POST /api/v1/events/{eventId}/ack или POST /api/v1/events/ack

Нужный файл подписи скачивается GET /api/v1/mig24/files/{id}/file

Архив, содержащий подписываемый документ и все файлы подписей, сформированные на момент запроса можно скачать - GET /api/v1/mig24/shared-file/{id}/last-file

После завершения подписания документа всеми сторонами можно скачать подготовленную в pdf справку-отчет POST /api/v1/mig24/shared-file/{sharedFileId}/report.

Шаблоны документов
swagger

ИС отправителя шаблона:
  • Создает документы через методы POST/api/v1/documents/
  • Создает PackageGroup на основании этих документов, указывая в запросе создания POST/api/v1/package-groups/, что PackageGroup является шаблоном. В body метода в поле «type» указывается, является ли PackageGroup обычным черновиком или черновиком-шаблоном.
Пример body:
{
  "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "type": "Template", -- "Default" для обычного документа
  "packages": [
    {
      "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
      "documentId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
      "isRecipientSignatureRequired": true
    }
  ],
  "recipientAbonent": {
    "code": "string",
    "name": "string",
    "inn": "string",
    "kpp": "string",
    "ogrn": "string",
    "email": "string"
  }
}
  • Пользователь отправляет PackageGroup-Template с помощью метода POST /api/v1/package-group-actions/send
Возможный body:
{ "packageGroupId": "3fa85f64−5717−4562-b3fc-2c963f66afa6" }
  • Получает обновление статуса Packages через GET /api/v1/events/package-status-updated
  • Пользователь может получить список возможных действий с группой пакетов с помощью метода GET /api/v1/package-groups/{id}/actions
  • Выполняет возможное действие POST /api/v1/packages/{id}/actions/template-revoke - Отозвать шаблон
ИС получателя шаблона:
  • Опрашивает очередь обновления статуса GET /api/v1/events/package-status-updated
  • Получает новые пакеты в статусе "Требуется принятие", помечает событие как обработанное (/api/v1/events/{eventId}/ack), показывает полученный шаблон пользователю
  • Выполняет 3 возможных действия с шаблоном:
POST /api/v1/packages/{id}/actions/receipt-notice - Принять шаблон / Формирует УС принятия
POST //api/v1/packages/{id}/actions/reject - Отказать в подписании / Формирует УС отказа
POST /api/v1/packages/{id}/actions/create-draft - Создать черновик / Создает черновиr на основании шаблона.
Далее черновик подписывается стандартными методами подписания.

История изменений
swagger

18.06.2026 - версия 1.110.0
  • Добавлен блок методов /api/v1/organization-users для добавления и редактирования данных сотрудников, включая настройку видов подписания сотрудника.

10.06.2026 - версия 1.108.0
  • Добавлен метод /api/v1/documents/informal/types - Метод возвращает список поддерживаемых неформализованных типов документов. Данный метод позволяет внешним интеграторам получить актуальный перечень доступных типов для корректной загрузки документов.

04.06.2026. - версия 1.107.0
  • Добавлен метод api/v1/mchd/powers получения полномочий из МЧД (по трем параметрам - номер, два ИНН)

01.06.2026 версия 1.106.0
  • Включено ограничение на прием файлов по типам (расширениям) документов.
  • В метод api/v1/abonents/me добавлена информации о текущем состоянии баланса (оплаты) Абонента

22.05.2026 - версия 1.105.0
  • Реализован блок методов (/api/v1/registration/abonent...) для регистрации абонента через API (включая подписание заявления)
  • Введено временное ограничение на удаление документов через API (пока можно удалять только черновики).

19.05.2026 - версия 1.104.0
  • Добавлены
POST Принять входящее приглашение - /api/v1/counteragent-requests/inbox/{requestId:guid}/accept,
POST Отклонить входящее приглашение - /api/v1/counteragent-requests/inbox/{requestId:guid}/reject,
POST Отозвать исходящее приглашение - /api/v1/counteragent-requests/inbox/{requestId:guid}/revoke,
DELETE Удалить контрагента (разорвать существующую связь между организациями) - разорвать связь с КА

08.04.2026 - версия 1.95.3
  • добавлено новое универсальное действие - Сформировать 2-й титул формализованного документа
Тип действия - AddSecondTitle
POST /api/v1/packages/{id}/actions/second-title

05.03.2026 - версия 1.88.2
  • Подключен функционал работы с шаблонами (между Абонентам оператора ЭДО.МИГ24)
25.02.2026 - версия 1.87.1
  • Добавлена возможность работы с очередями, используя режим смещения (offset)
03.02.2026 - версия 1.85.0
  • Запущены новые методы подписания документов через возможный перечень действий с документом. Старые методы подписания причислены к архивным, но будут продолжать поддерживаться, пока их используют.
  • Подключена возможность через api указывать сотрудника, которому необходимо передать документ на подпись
15.01.2026 - версия 1.82.0
  • реализована поддержка строке 5б УПД - авансовая счет-фактура (элемент «Сведения о сопроводительных документах, уточняющих обстоятельства факта хозяйственной жизни (СопрДокФХЖ)» (таблица 5.8 Приказа № 970))