Что делать, когда сервис обновляет API, а интеграция падает

«Оплатила два часа назад, а подтверждение не пришло. У вас всё работает?»

Сообщение висит в чате, а в ленте заявок с самого утра пусто. Менеджер открывает почту, потом панель управления, потом звонит вам. И вот тут выясняется: ночью сторонний сервис поменял правила обмена данными.

По опыту внедрений ломается обычно не сам сайт, а тонкая ниточка, которая связывает его с чужим сервисом.** И замечаете вы это по молчащей ленте заявок. Клиент не дождался подтверждения и ушёл к тем, у кого всё работает. Менеджер переносит заказы руками и тихо злится. Вы тратите вечер на переписку с поддержкой вместо нормальной работы.

Что дальше: где интеграция ломается первой, какие изменения в чужом программном интерфейсе бьют больнее всего, что ИИ переписывает сам, а где зовут человека, как оформить тесты и оповещения, а также что делать, если поток заявок уже встал. О ручном труде и его цене: [Сколько ваш бизнес платит за рутину и как сократить расходы с помощью ИИ](/blog/skolko-vash-biznes-platit-za-rutinu-i-kak-sokratit-rashody-s-pomoschyu-ii).

Коротко

Ломается не «интеграция вообще», а её слабые места**: адреса запросов, названия полей, коды ответов. Найти их можно за один вечер.

Больнее всего бьют переименование полей, смена версии и лимиты на число обращений.

ИИ сам правит код запросов и разбора ответа, а логику и доступы согласует человек.

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

Об обновлениях сервиса узнавайте раньше клиента: подписка на рассылку и свой тестовый контур.

Где ваша интеграция ломается первой — и как найти все слабые места за один вечер

Сообщение от клиента приходит в мессенджер: «оплатил, а заказ не оформился». Вы открываете панель и видите заказ в статусе «ожидает оплаты». Деньги ушли, заявка не создалась. И главное: непонятно, где порвалась связь.

Ревизию мы всегда начинаем одинаково — с живого списка зависимостей, а не со схемы, которую кто-то нарисовал год назад.

Выпишите все точки стыковки

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

Без такого списка поломка выглядит как «что-то сломалось». А со списком та же ситуация читается конкретно: не отвечает служба доставки, и заказы копятся в статусе «собран».

Если склад у вас до сих пор ведётся отдельно от заказов, начните с [этой инструкции](/blog/avtomatiziruyte-upravlenie-skladom-i-zakupkami-poshagovaya-instruktsiya): иначе остатки придётся сверять руками.

Что вы отдаёте и что ждёте в ответ

По каждой точке две колонки. Что уходит наружу: номер заказа, сумма, состав корзины, адрес, телефон клиента. Что возвращается и в каком виде: подтверждение оплаты, трек-номер, отметка «отгружено», идентификатор записи во внешней системе.

Теперь смотрите на вторую колонку. **Слабое место почти всегда там, где ответа может просто не прийти.** Если подтверждение оплаты «зависло», первым об этом сообщит клиент, и напишет злым голосом.

> Совет: отметьте те связи, разрыв которых останавливает деньги. Их немного: создание заказа, подтверждение оплаты, передача заказа в доставку, уведомление клиента.

Соберите карту зависимостей

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

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

Три вида изменений в чужом API, которые бьют больнее всего

Есть три сценария, с которыми мы сталкиваемся чаще всего. Про первые два вы узнаёте из логов. Про третий — от клиента, и это самое неприятное.

Поменялась авторизация

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

Признак простой: вечером всё работало, утром перестало, и на вашей стороне никто ничего не трогал.**

Поменялись поля и форматы

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

Ужесточились лимиты и пагинация

Запросов в минуту теперь меньше, чем раньше. Страницы считаются с нуля, а вместо общего количества приходит курсор, который нужно тащить в следующий запрос. Выгрузка заказов и остатков за месяц обрывается на середине, но система молчит: ошибок нет, просто часть данных не доехала. Если через обмен как раз идёт склад, [инструкция по учёту склада и закупок](/blog/avtomatiziruyte-upravlenie-skladom-i-zakupkami-poshagovaya-instruktsiya) помогает увидеть, где именно теряются позиции.

Тихие изменения

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

> Совет: держите рядом копию документации сервиса на дату, когда интеграцию сдавали. Сравнить старое описание ответа с новым быстрее, чем читать логи.

Что ИИ действительно переписывает сам, а где зовут человека

Сервис ни с того ни с сего отвечает ошибкой на поле, которого неделю назад в ответе не было. Заявки из этого канала встали, и клиенты уже пишут в мессенджер.

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

Что отдаём без разговоров

Код самого запроса: адрес метода, заголовки, параметры, тело.

Разбор ответа: новые поля, переименования, форматы даты и телефона.

Обработку сбоев и повторов: где запрос можно послать снова, а где повтор всё испортит.

Тесты на сохранённых ответах сервиса, чтобы правка не задела соседние сценарии.

Это ремесло. Тут ИИ работает как программист, только не устаёт к третьему часу ночи и не забывает, что делал в прошлый раз.

Где останавливаемся и зовём вас

Дальше начинается другое. Допустим, сервис поменял смысл статуса: раньше «подтверждена» значила одно, теперь другое. Код поправить легко. А решить, что это значит для записи и для обещаний клиенту, может только владелец.

Что важнее — сохранить визит клиента, который приносит выручку не первый год, или принять новую заявку из рекламы? Отменять визит автоматически или звонить и договариваться? На таких вопросах ИИ тормозит и ждёт вас.

Машина умеет выполнить правило, но придумать его за вас не может. И это не её слабость, а ваша страховка.**

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

Мы часто видим обратное: предприниматель радуется, что «теперь всё само», а через месяц узнаёт правила собственного бизнеса из логов интеграции. А правила эти он должен был задать сам.

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

Как оформить автотесты, чтобы они ловили поломки, а не создавали шум

Проверки вокруг интеграции заводят не для красоты отчёта. Смысл один: утром вы открываете список, он зелёный, и вы спокойно занимаетесь делами, потому что заявки доходят.

Три проверки, которые закрывают почти всё

Проверка доступности. Раз в несколько минут стучимся в чужой сервис и фиксируем, ответил он или промолчал. Дешёвая, простая, ловит обрывы связи и плановые работы.

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

Сквозная проверка. Заводим тестовую заявку и ведём её до конца: отправилась, вернулся номер, статус сменился, клиенту ушло подтверждение. Отдельные проверки такого не видят, а эта видит весь путь.

Почему структура важнее конкретного значения

Первым делом обычно пишут что-то вроде «в поле статуса должно быть „новый“». И получают красный список в тот день, когда сервис добавил ещё один статус. Значение поменялось, интеграция работает. А вы уже читаете логи.

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

Проверка структуры отвечает на вопрос «мы всё ещё понимаем друг друга», проверка значения — «помнит ли сервис прошлый вторник».**

> Совет: упал тест на конкретном значении — сначала посмотрите, жалуется ли клиент. Если нет, это шум. Убирайте сразу, а не разбирайтесь в полночь.

Чтобы список не превратился в мусор

Правила простые. На одну проверку одна причина падения. Тест, который падает постоянно, быстро отключают, и он перестаёт что-либо охранять. Проверки на живых данных клиентов держите отдельно от тех, что гоняют тестовую заявку.

Но главное: раз в неделю открывайте список упавших и вычищайте кричащие впустую. Иначе выходит как у многих: сорок красных строк, все давно пролистывают их не глядя, а настоящая поломка тихо ждёт третьего дня. По сути это та же борьба с рутиной, о которой мы писали в [Сколько ваш бизнес платит за рутину и как сократить расходы с помощью ИИ](/blog/skolko-vash-biznes

Как узнавать об изменениях раньше клиента

Плохую новость обычно приносит клиент. «Заявки не приходят», «оплата не проходит». И о поломке вы узнаёте от человека, который платит вам деньги, а не от своей системы.

Сервисы почти всегда предупреждают заранее. Просто предупреждения приходят туда, куда никто не смотрит.**

Куда смотреть

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

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

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

> Совет: пусть уведомление приходит вам лично. В общем чате разработки его увидят, но решение «звонить клиентам или подождать» всё равно принимать вам.

Тесты по расписанию, а не только при выкладке

Автотесты запускают перед выпуском новой версии, видят зелёный результат и успокаиваются. **Свой код вы не меняли. Изменился чужой.**

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

Пока поломку не видите вы, её видит клиент. Всё, что нужно, — опередить его хотя бы на день.

Порядок действий, если обновление уже сломало поток заявок

Поломку замечаешь не по логам, а по тишине в телефоне. Заявки шли каждые полчаса, и вдруг пусто. Первое желание — открыть код и править. Не надо. Сначала посчитайте ущерб, иначе через два часа будете знать, что «что-то сломалось», но не знать, кого потеряли.

Первый час: масштаб

Откройте журнал заявок и найдите последнюю успешную. Дальше по списку: сколько обращений не дошло и из каких каналов, не было ли среди них оплаченных. Выгрузите телефоны и напишите каждому от лица администратора: «Здравствуйте! Ваша заявка на 14:00 не сохранилась из-за технического сбоя. Подтверждаю запись вручную». По опыту, после такого сообщения многие остаются, а молчание теряет всех.

Запасной путь включаем сразу

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

Лог ошибок отдаём ИИ

Соберите в один файл всё, что говорит чужой сервис: текст ошибки, время, пример отправленного запроса, ответ сервиса, версию. Без этого ИИ только гадает, а с этим правит уверенно: подставит нужное имя поля, поправит формат даты. Зовите человека, если менялась логика оплаты или сервис требует новую авторизацию с доступом к деньгам. Или если непонятно, что делать с уже принятыми заявками. Тут без ответственного за интеграцию не обойтись. Про остальную рутину, которую стоит отдать автоматике, у нас есть [отдельный разбор](/blog/skolko-vash-biznes-platit-za-rutinu-i-kak-sokratit-rashody-s-pomoschyu-ii).

Тесты и возврат трафика

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

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

Пример: как это выглядит на практике

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

Утром администратор увидел пустой список на день. А клиенты приезжали. «Я же вчера записался на десять», — говорил один у стойки. Сервис расписаний поменял названия полей в ответе, и разбор перестал их узнавать. Про поломку узнали от клиента. Система молчала.

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

Незнакомый формат ловит машина. Решение, можно ли отдавать правку дальше, остаётся за человеком.**

Теперь утро начинается со сводки: сколько записей принято, были ли сбои. Клиент получает короткое подтверждение: «Добрый день! Ваша запись на четверг, 10:00, подтверждена. Если планы изменились, ответьте „перенести“». Как такая запись стыкуется со складским учётом, мы разбирали в [материале про автосервисы](/blog/onlayn-zapis-i-skladskoy-uchet-v-avtoservise-kak-nastroit-i-kontrolirovat).

> Совет: держите резервный канал на случай сбоя — сообщение администратору в мессенджер дешевле потерянной заявки.

Ошибки, на которых спотыкаются почти все

Чинить руками, пока горит.**

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

Верить, что «предупреждали».**

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

Пускать ИИ править рабочий код без проверки.**

Он хорошо переписывает и добавляет тесты, но придумывает лишнее: подставляет несуществующие поля, «улучшает» логику, которую трогать не просили. Пусть работает на копии, а человек смотрит, что именно поменялось.

Писать тесты на всё подряд.** От них много шума, и на проверки перестают смотреть. Держите их на главном: заявка ушла, ответ разобрался, клиенту пришло подтверждение.

Узнавать о поломке от клиента.** Самое дорогое. Ставьте простую проверку: раз в несколько минут к сервису уходит пробный запрос, и если он не проходит, сообщение падает вам, а не в отзывы.

> Совет: ведите короткий список «что мы ждём от чужого сервиса» и правьте его сразу, как узнали об изменении.

Чек-лист: что сделать на этой неделе

Выпишите все сервисы, которые участвуют в приёме заявок: оплата, склад, рассылки, доставка.

Откройте журнал обмена и найдите ошибки за последние дни. Журнала нет — заведите его сегодня.

Разделите связи на критичные и второстепенные: где из-за сбоя заявка теряется, а где она просто встаёт в очередь.

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

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

Подпишитесь на рассылку изменений и назначьте, кто читает её утром.

Прогоните сценарий руками: создайте заявку, оплатите её и проверьте, дошла ли она до склада и до клиента.

Заведите по одному автотесту на каждый критичный сценарий.

Договоритесь с исполнителем о сроке: сколько часов даётся на починку после чужого обновления.

> Совет: держите список связей в одном файле, чтобы в панике не рыться в переписках.

Вопросы и ответы

Как понять, что нас сломало именно обновление чужого сервиса?

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

ИИ правда перепишет интеграцию сам?

Там, где поехало название поля или порядок параметров, да, справится за вечер. Логику оплаты и списания остатков он не трогает: рядом нужен человек, который знает ваш процесс. Подробнее о том, что стоит отдавать машине, мы писали в материале [Сколько ваш бизнес платит за рутину и как сократить расходы с помощью ИИ](/blog/skolko-vash-biznes-platit-za-rutinu-i-kak-sokratit-rashody-s-pomoschyu-ii).

Как убедиться, что после правки всё работает?

Создайте тестовый заказ и проведите его до конца: от заявки до записи в учёте. Дошли — интеграция жива. Без такой проверки смотреть на зелёные галочки смысла мало.

Можно узнать об изменениях раньше клиента?

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

> Совет: назначьте одного человека, который раз в месяц заглядывает в такие уведомления. Иначе этим не занимается никто.

Что делать, если поток заявок уже встал?

Сначала приём. Заведите временную форму, которая пишет обращения в таблицу или на почту, чтобы ничего не потерялось. Потом чините обмен. Клиенту напишите коротко: «Заявку получили, перезвоним в течение часа».

Вывод

Обновление чужого API — это не авария, а расписание. Кто-то поменяет поле или добавит обязательный параметр, и вопрос лишь в том, узнаете вы об этом из письма или из тишины в заявках. **Интеграцию, которую можно переписать и проверить без вашего участия, ломающее обновление уже редко застаёт врасплох.**

Можно каждую поломку тушить руками и надеяться, что она придёт в рабочее время. А можно один раз собрать связку, где ИИ правит код и прогоняет тесты, а человек смотрит на результат. В Workintelligence мы делаем второе: [оставьте заявку на разработку](/#custom) — соберём систему под ваши процессы и покажем рабочую версию в короткий срок.