Подключите Инвойсбокс с помощью ИИ-агента

Это так же просто, как поставить виджет: скопируйте промпт и отправьте своему агенту — он прочитает документацию в машиночитаемом виде, возьмёт схемы API и соберёт интеграцию.

Прочитай https://docs.invoicebox.ru/llms.txt и изучи мой проект. Сначала предложи план: сценарий оплаты и какие настройки понадобятся. Версия API — /v3/. Проверочные запросы делай только на демо-магазине и без реальных персональных данных. Боевые вызовы и денежные операции — только после моего подтверждения. Реализуй создание заказа, восстановление после таймаута по merchantOrderId, проверку подписи уведомления, сверку суммы и повторную обработку одного уведомления без двойной оплаты. Токены держи в переменных окружения. В конце запусти тесты и перечисли допущения.

Агент, который умеет действовать

Всё, что ниже, помогает агенту прочитать документацию. Если нужно, чтобы он выставлял счета и проверял оплату сам, подключите MCP-сервер Инвойсбокс: ассистент получит восемь инструментов с подтверждением денежных операций человеком.

Что получает агент

llms.txt

Оглавление всей документации со ссылками на markdown, инструкции по интеграции и правила работы: базовый URL, авторизация, лимиты, восстановление после таймаута, типовой сценарий оплаты.

llms-full.txt

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

OpenAPI 3.1

Машиночитаемый контракт публичных методов: пути, схемы запросов и ответов, типы полей и enum-значения.

Markdown любой страницы

Добавьте .md к адресу страницы или используйте /raw/<путь>.md — без HTML-разметки.

Демо-доступ

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

Схемы и SDK

Схема OpenAPI 3.1 и коллекция Postman: все операции публичного контракта одним файлом (точное число — в самом файле). Методы модулей проведения платежей, Инвойсбокс.Бизнес и агентской схемы описаны на страницах, но в файл пока не попали — их схем у нас нет. Где чей контракт — машиночитаемо в coverage-manifest.json: по каждому методу сказано, брать ли его из схемы или со страницы.

Как называются сущности

Карта терминов, чтобы модель не путала русские и английские имена — «invoice» здесь ложный друг переводчика:

Order — заказ. Его формирует поставщик (магазин) через POST /v3/billing/api/order/order, он с этим заказом работает и в его рамках получает информацию об оплате. Когда документация говорит «выставить счёт покупателю», технически создаётся именно Order.
OrderContainer — контейнер заказов: группа заказов, объединённых одним процессом оплаты покупателя, в том числе от разных поставщиков.
Invoice — счёт. Его получает и оплачивает покупатель; счёт формируется на контейнер (группу) заказов, поэтому один счёт может нести несколько заказов от одного или нескольких поставщиков.
Payment — оплата: транзакция в пользу оплаты счёта. Счёт может быть оплачен одной или несколькими транзакциями.
«Магазин» — Merchant, точка продаж с токеном и настройками; «организация» — Counterparty, юрлицо, которому принадлежат магазины.

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

Критерии готовности интеграции — машиночитаемым файлом: acceptance-contract.json (он же по-человечески — чеклист запуска).

Выгрузки по разделам

Раздел целиком, с текстом всех его страниц — когда полный файл в контекст не влезает: llms-api.txt · llms-id.txt · llms-merchant.txt · llms-payment.txt · llms-business.txt · llms-marketplace.txt · llms-partner.txt · llms-scenarios.txt · llms-dictionary.txt · llms-design.txt