API-интеграция ломается не на коде, а на плохом ТЗ и хаосе в данных

API-интеграция ломается не на коде, а на плохом ТЗ и хаосе в данных

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

Перед запуском проверьте 4 вещи:
— какие поля обязательны, а какие можно пустыми;
— кто создает, обновляет и закрывает сущность;
— как выглядят ошибки и что считать повторной отправкой;
— где хранится лог: запрос, ответ, время, ID записи. 🔧

Отдельно продумайте идемпотентность: если запрос ушел дважды, система не должна создавать дубль. Для этого нужен стабильный внешний идентификатор и понятное правило обновления. Иначе любая ретрай-логика превратится в источник мусора.

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

Если хотите, чтобы API-интеграция жила долго, начинайте не с метода, а с карты данных, правил ошибок и логирования: это экономит часы ручной правки и убирает половину скрытых багов.