Цена интеграции по API включает обработку сбоев, а агенты меняют стоимость написания связки

Начните с описания операции: откуда приходит запись, куда попадает и что считается завершением. «Интеграция с внешним API» не отвечает на вопрос, нужна ли только передача новых заказов или ещё изменения, отмены и загрузка старой истории.

Для примера возьмём оплату и выдачу доступа. Бизнесу нужен доступ к купленному продукту и уведомление покупателю; успешный ответ сервера лишь один из промежуточных признаков. Если уведомление осталось неотправленным, сценарий не завершён.

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

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

Правила зависят от провайдера. Stripe предупреждает о повторной доставке событий и не гарантирует их порядок; GitHub не повторяет неудачные webhook-доставки автоматически. Webhook здесь означает уведомление, которое внешний сервис отправляет вашей системе при событии.

Для создания и изменения объектов Stripe документирует ключ идемпотентности: после выполнения запроса повтор с тем же ключом возвращает сохранённый результат. Это свойство конкретного API, а не обещание для любой связки. Подрядчик должен назвать способ восстановления для вашего сервиса и показать его в приёмке.

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

Это найденная ошибка в собственном сайте, а не клиентский случай потери денег. Для обмена между системами из неё следует правило: у каждого нужного бизнесу шага есть свой результат и способ повторить незавершённое. Заранее назначьте человека, который разбирает такие записи; ответственность за ошибки ИИ не исчезает после генерации кода.

В уроке «Руль, окно и сторож» нашей программы агентной разработки эта работа разделена на правила, видимый ход выполнения и наблюдение за сбоями. Наличие журнала ещё не гарантирует, что пропуск заметят. Наши случаи показывают, какие правила менялись после таких ошибок.

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

Если агент сократил работу над кодом, это может изменить оценку этой части сметы. Из этого не следует одинаковая скидка на согласование сценариев, ожидание доступа или разбор расхождений. Когда ИИ не ускорил разработку, искать задержку стоит во всём пути до принятого результата.

В открытом эфире машины видно, что наш сайт получает изменения от агентной разработки. На кадре ниже счётчик коммитов, а не стоимость интеграции. У нас нет клиентского кейса с сопоставимыми сметами на одну связку до и после агентов, поэтому процент экономии мы здесь не называем.

Попросите разделить разовую разработку, расходы на работающий продукт и согласованное сопровождение. Подключение API может зависеть от тарифа внешнего сервиса; хранение записей обмена и выполнение фоновых задач требуют инфраструктуры. Эти расходы способны продолжиться после приёмки кода.

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

В общей сумме укажите единицу каждого расхода: работа по согласованному объёму, месяц подписки, запрос или объём хранения по тарифу провайдера. Для переменной части приложите тариф и допущение по нагрузке. Так сравнение покажет, где подрядчик изменил объём работ, а где изменился ваш прогноз использования.

У нас разработка по подписке в тарифе «Один проект» стоит 250 000 ₽ в месяц. По публичным условиям на 8 октября 2026 года это один продукт и один поток работы: следующая задача ждёт в очереди. Очередь изменений обмена между системами подходит под такой способ работы.

Эта сумма не является фиксированной ценой отдельной интеграции. Если вам нужна одна законченная связка без дальнейшей очереди изменений, сравните подписку с разовым предложением на тот же объём. Число принятых изменений зависит от самих задач и доступности внешних систем.

На странице услуги указано, что расходы работающего продукта на хостинг, облако и сторонние сервисы оплачивает заказчик. Поэтому бюджет внешних API и инфраструктуры считайте отдельно. Сопровождение с ночными дежурствами тоже не следует молча включать в цену разработки: у нашей услуги ночных дежурств нет.

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

Хороший пример приёмки: повторное событие не создаёт второй заказ, а неотправленное уведомление можно довести до результата. Плохой пример: исполнитель показывает успешный ответ API и предлагает считать задачу завершённой. Между этими демонстрациями находится существенная часть объёма интеграции.

Проверка должна оставлять понятный след: запись события, результат в целевой системе и состояние незавершённого шага. Если возникло расхождение, согласуйте владельца разбора и способ восстановления. Для ограничения запросов GitHub прямо требует дождаться разрешённого времени повтора; непрерывный повтор не заменяет обработку ошибки.

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

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

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

Сравнивайте сметы на одинаковые сценарии и результаты приёмки.

Включайте восстановление после сбоев в согласованный объём разработки.

Проверяйте повтор, потерянный ответ и пропущенное событие до рабочего запуска.

Считайте внешние API, инфраструктуру и сопровождение отдельными расходами.

Оценивайте работу агента по принятой связке, а не по объёму написанного кода.