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

Как проверить вебхуки CRM перед оплатой интеграции: тестовые заявки, логи и SLA

Автор и проверка: Алексей Воронов, редакционный координатор ormobil.com · Факты, документы, риски и применимость · Обновлено: 03 апреля 2026 г.

Перед оплатой CRM-интеграции проверьте не «наличие вебхука», а полный путь события: тестовая заявка → отправка webhook → приём внешним сервисом → запись в логах → корректное изменение карточки в CRM. Минимум нужно

Какие вебхуки CRM нужно проверить до оплаты

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

В CRM обычно критичны следующие типы вебхуков:

1. Создание лида или сделки

Проверяется, создаётся ли карточка при поступлении формы, звонка, заявки с сайта, мессенджера, маркетплейса или внешнего сервиса. Важно увидеть не только факт создания, но и заполнение полей: имя, телефон, email, источник, UTM-метки, город, товар или услуга.

2. Обновление статуса

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

3. Назначение ответственного

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

4. Передача оплаты или подтверждения заказа

Для связки CRM с платёжным сервисом, кассой, складом или личным кабинетом нужно проверить сумму, валюту, номер заказа, статус оплаты, дату, идентификатор транзакции. Даже расхождение в 1 символе в order_id может создать дубли и ручную сверку.

5. Отмена, возврат, отказ клиента

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

6. Повторная заявка и дубль

Если клиент оставил форму дважды с одного телефона, CRM должна действовать по правилам: обновить существующую карточку, создать повторную сделку, добавить комментарий или поставить задачу менеджеру. Это должно быть описано заранее.

7. Ошибка внешнего сервиса

Нужно проверить, что происходит, если принимающая сторона вернула HTTP 400, 401, 403, 404, 409, 429 или 500. Хорошая интеграция не должна молча терять событие.

Перед тестированием запросите у подрядчика схему: какие события отправляются, на какие URL, в каком формате, с какими обязательными полями и кодами ответа. Минимальный комплект документов: ТЗ, смета, карта событий webhook, пример JSON-payload, акт приёмки, регламент поддержки. Если вместо этого есть только переписка в мессенджере, приёмка будет спорной.

Для тиража или проекта запросите 3 сметы: базовую, оптимальную и срочную; отдельно отметьте сроки 3–7 дней, гарантию и стоимость переделки. Например, базовая проверка одного-двух вебхуков может занимать 1–2 рабочих дня, полноценная приёмка интеграции с логами, ретраями и SLA — 3–7 рабочих дней, а срочный запуск обычно дороже на 20–50% из-за параллельной работы разработчика и тестировщика.

Тестовые заявки для проверки событий, дублей и обязательных полей

Тестовые заявки должны имитировать реальные ситуации, а не состоять из одной формы с именем «Тест». Лучше заранее подготовить таблицу с 10–15 сценариями и отметить ожидаемый результат по каждому. Так вы проверите не только код, но и бизнес-логику.

Базовая успешная заявка

Создайте заявку с корректными данными:

• имя: Иван Петров;

• телефон: +7 999 123-45-67;

• email: test@example.com;

• источник: сайт;

• UTM: utm_source=yandex, utm_campaign=test_crm;

• услуга: консультация;

• комментарий: «Тестовая заявка перед приёмкой».

Что проверить:

• карточка создана в нужной воронке;

• все обязательные поля заполнены;

• источник не потерялся;

• UTM-метки сохранились без обрезки;

• ответственный назначен по правилу;

• в логах есть событие с точным временем;

• внешний сервис получил HTTP 200 или 201;

• webhook_id или request_id можно найти и в CRM, и во внешней системе.

Если карточка появилась, но без UTM или без телефона, интеграция не готова к оплате. Для бизнеса это не «мелкая правка», а потеря аналитики и возможности связаться с клиентом.

Заявка с пропущенным обязательным полем

Отправьте форму без телефона или email — в зависимости от того, что в вашем процессе считается обязательным. Система должна не просто «сломаться», а отработать предсказуемо:

• отклонить заявку с понятной ошибкой;

• записать ошибку в лог;

• показать, какое поле отсутствует;

• не создать пустую карточку;

• не отправить менеджеру неполную задачу.

В логах должна быть конкретика: `missing required field phone`, `validation_error`, `HTTP 400`, а не общая запись «ошибка отправки». Если подрядчик не может показать, где видно пропущенное поле, поддержка после запуска будет затруднена.

Дубль по телефону

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

• обновлять существующий лид;

• создавать новую сделку в той же карточке клиента;

• добавлять комментарий;

• ставить задачу менеджеру;

• блокировать повторную заявку в течение заданного времени.

Практичный ориентир: окно дедупликации часто задают от 15 минут до 24 часов — в зависимости от процесса продаж. Для срочных услуг может быть достаточно 15–60 минут, для B2B-заявок — 24 часа и больше. Главное, чтобы правило было записано в ТЗ, а не придумано после спора.

Что должно быть видно:

• первая заявка создала карточку;

• вторая не создала хаотичный дубль;

• связь между заявками понятна менеджеру;

• лог содержит отметку `duplicate_detected` или аналогичный признак;

• при необходимости создана повторная сделка, а не потерян запрос клиента.

Дубль по email и разный телефон

Этот сценарий нужен, если клиенты часто оставляют корпоративную почту, но звонят с разных номеров. Проверьте, как CRM определяет одного клиента: по email, телефону, связке email+телефон или внешнему ID.

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

Неверный формат телефона

Отправьте телефон в нескольких форматах:

• `89991234567`;

• `+7 999 123-45-67`;

• `7 (999) 123 45 67`;

• `+79991234567`;

• `12345`.

Корректные варианты должны нормализоваться к единому формату, например `+79991234567`. Некорректный номер должен быть отклонён или помечен как ошибка валидации. Если CRM принимает `12345` как рабочий телефон, менеджеры получат мусорные карточки, а отчёт по лидам будет завышен.

Заявка с длинным комментарием

Отправьте комментарий на 1000–3000 символов. Это проверяет ограничения полей, экранирование спецсимволов и переносы строк. Частая ошибка — комментарий обрезается до 255 символов без предупреждения или ломает JSON из-за кавычек.

Проверьте:

• текст не обрезан без отметки;

• кавычки, переносы строк и эмодзи не ломают payload;

• лог хранит тело запроса или безопасную маску;

• CRM отображает комментарий читаемо.

Ошибка авторизации

Попросите подрядчика временно использовать неверный токен на тестовом контуре или показать результат такого сценария в dev-среде. Ожидаемое поведение:

• CRM или внешний сервис возвращает HTTP 401 или 403;

• событие попадает в очередь повторной отправки, если ошибка временная;

• ответственный получает уведомление;

• в логах не раскрывается полный токен;

• ошибка не считается успешной доставкой.

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

Таймаут принимающей стороны

Сымитируйте задержку ответа внешнего сервиса на 5–10 секунд. Нужно понять, что делает интеграция:

• ждёт ответ;

• прерывает запрос по таймауту;

• повторяет отправку;

• ставит событие в очередь;

• сообщает об ошибке.

Для большинства CRM-интеграций разумный timeout — 3–10 секунд. Если webhook висит 30–60 секунд, менеджер может видеть задержки в интерфейсе, а очередь событий начнёт накапливаться при пиковом трафике.

Массовая отправка заявок

Отправьте 20–50 тестовых заявок за короткий период. Это не полноценное нагрузочное тестирование, но оно показывает, выдерживает ли интеграция обычный всплеск после рекламы или рассылки.

Проверьте:

• нет ли пропущенных событий;

• порядок обработки сохраняется там, где он важен;

• лимиты API не превышены;

• при HTTP 429 включаются ретраи;

• в логах можно отфильтровать пачку по времени и request_id.

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

Критерии проверки

Ниже — практические критерии, по которым можно принимать или не принимать вебхуки CRM. Их удобно перенести в акт приёмки и отмечать результат: «пройдено», «не пройдено», «требует исправления».

1. Событие срабатывает только в нужный момент

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

Хороший вариант: событие срабатывает только при конкретном действии:

• создан новый лид;

• статус изменён с «Новая» на «В работе»;

• оплата перешла в «Успешно»;

• назначен ответственный;

• заявка перешла в нужную воронку.

Критерий приёмки: в логах видно исходное событие, старое значение и новое значение, если это изменение статуса.

2. Обязательные поля не теряются

Минимальный набор для лида:

• имя или название клиента;

• телефон или email;

• источник;

• дата и время создания;

• ID заявки;

• ID клиента или сделки;

• услуга/товар;

• ответственный;

• статус;

• комментарий.

Для платёжных событий дополнительно:

• сумма;

• валюта;

• номер заказа;

• ID транзакции;

• статус платежа;

• дата оплаты;

• признак возврата.

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

3. Есть единый идентификатор события

У каждого события должен быть идентификатор: `request_id`, `event_id`, `webhook_id` или другой уникальный ключ. Без него невозможно доказать, где потерялась заявка: в CRM, на стороне подрядчика, у внешнего сервиса или в сети.

Критерий приёмки:

• ID виден в CRM;

• ID виден в логах интеграции;

• ID передаётся во внешний сервис;

• по ID можно найти событие за 1–2 минуты;

• повторная отправка не создаёт новый бизнес-дубль без связи с исходным событием.

4. Корректно обрабатываются HTTP-коды

Подрядчик должен показать таблицу реакции на коды ответа:

• 200/201 — событие доставлено успешно;

• 400 — ошибка данных, нужен разбор payload;

• 401/403 — проблема авторизации или прав;

• 404 — неверный endpoint или ресурс;

• 409 — конфликт, например дубль;

• 429 — превышен лимит запросов, нужны ретраи;

• 500/502/503/504 — ошибка сервера, нужны ретраи и уведомление.

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

5. Настроены ретраи

Ретраи — это повторные попытки отправки webhook при временной ошибке. Без них любая кратковременная недоступность сервиса превращается в потерянные заявки.

Практичный минимум:

• 3–5 попыток повторной отправки;

• интервалы: 1 минута, 5 минут, 15 минут, 60 минут;

• отдельное правило для HTTP 429 и 5xx;

• отсутствие ретраев для явных ошибок данных 400, если payload некорректен;

• лог каждой попытки.

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

6. Ошибки видны без доступа разработчика к серверу

Если каждый раз для проверки нужно «попросить программиста посмотреть консоль», поддержка будет медленной. Логи должны быть доступны ответственному сотруднику, тимлиду или администратору CRM.

Минимально полезный лог содержит:

• дату и время с часовым поясом;

• тип события;

• ID сделки или лида;

• endpoint;

• статус отправки;

• HTTP-код;

• длительность запроса в миллисекундах;

• текст ошибки;

• номер попытки;

• request_id.

Критерий приёмки: пользователь с согласованной ролью может открыть журнал и найти событие без прямого доступа к production-серверу.

7. Персональные данные не раскрываются лишним людям

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

Допустимый подход:

• телефон отображается частично: `+7999****567`;

• токены и ключи не выводятся полностью;

• пароли не логируются;

• доступ к логам ограничен ролями;

• срок хранения логов определён, например 30, 60 или 90 дней.

Критерий приёмки: подрядчик показывает пример лога без раскрытия секретов и фиксирует порядок доступа в регламенте поддержки.

8. Есть тестовый и рабочий контур

Если все проверки проходят сразу на боевой CRM, есть риск испортить реальные сделки, отправить клиентам тестовые уведомления или создать мусор в отчётах. Нормальный вариант — тестовая воронка, sandbox, отдельный endpoint или хотя бы явный признак `test=true`.

Критерий приёмки:

• тестовые заявки отделены от реальных;

• тестовые уведомления не уходят клиентам;

• после проверки можно удалить или пометить тестовые карточки;

• правила на production включаются только после согласования.

9. Сроки исправления ошибок определены заранее

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

• критическая: теряются заявки, не создаются сделки, неверно передаётся оплата;

• высокая: дубли, неверный ответственный, потеря источника;

• средняя: некорректный комментарий, несущественная задержка;

• низкая: опечатка в названии поля, неудобный текст ошибки.

Практичный SLA по исправлениям:

• критическая ошибка — реакция до 2 часов, исправление в течение 1 рабочего дня;

• высокая — реакция до 4 часов, исправление 1–2 рабочих дня;

• средняя — исправление 3–5 рабочих дней;

• низкая — в ближайший плановый релиз.

Критерий приёмки: сроки записаны в договоре, приложении, акте или регламенте, а не обещаны устно.

10. Есть понятный порядок правок

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

Типовая формулировка для защиты клиента: «В стоимость включены 2 раунда исправлений по замечаниям к согласованному ТЗ. Исправление дефектов, связанных с несоответствием ТЗ, выполняется без дополнительной оплаты в течение гарантийного срока».

Гарантийный срок лучше фиксировать явно: например, 14 или 30 календарных дней после подписания акта. Если гарантия не указана, подрядчик может считать любую проблему новой платной задачей.

Как читать логи интеграции и отличать сбой CRM от ошибки подрядчика

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

Шаг 1. Найдите событие в CRM

Откройте карточку тестовой заявки и зафиксируйте:

• ID лида или сделки;

• время создания;

• источник;

• статус;

• ответственного;

• заполненные поля;

• комментарии и служебные записи.

Если карточка в CRM не создана, проблема может быть до CRM: форма сайта, виджет, телефония, endpoint, авторизация, лимит API. Если карточка создана, но webhook не отправился, проблема уже внутри настройки события или правил CRM.

Шаг 2. Сравните время события и время отправки webhook

Разница между созданием заявки и отправкой webhook должна быть понятной. Для большинства процессов нормальна задержка до 1–30 секунд. Если webhook уходит через 10–15 минут без объяснения, это влияет на работу менеджеров и автоматизацию.

Смотрите не только время, но и часовой пояс. Частая путаница: CRM пишет время в локальном часовом поясе, сервер — в UTC, а внешний сервис — ещё в другом формате. В акте приёмки лучше указать единый стандарт: например, хранить системное время в UTC, а в интерфейсе показывать локальное.

Шаг 3. Проверьте endpoint и метод

В логах должны быть видны:

• URL отправки;

• метод: обычно POST;

• статус ответа;

• длительность запроса;

• номер попытки;

• ID события.

Если webhook отправлен не на тот endpoint, это ошибка настройки. Если endpoint правильный, но внешний сервис возвращает 401, проверьте токен и права. Если возвращает 400, смотрите тело запроса: часто причина в отсутствующем поле или неверном формате.

Шаг 4. Сравните payload с карточкой CRM

Payload — это данные, которые CRM передала во внешний сервис. Нужно сравнить:

• совпадает ли телефон;

• не потерялся ли email;

• передались ли UTM;

• не изменился ли ID сделки;

• корректна ли сумма;

• передан ли статус;

• нет ли пустых обязательных полей.

Если в CRM данные есть, а в payload их нет, проблема в настройке webhook или маппинге полей. Если в payload данные есть, а внешний сервис их не принял, проблема может быть на стороне принимающего сервиса или в формате, который согласовал подрядчик.

Шаг 5. Оцените HTTP-код и тело ответа

HTTP 200 не всегда означает, что бизнес-событие обработано правильно. Иногда внешний сервис возвращает 200, но внутри ответа пишет `error=true`. Поэтому подрядчик должен учитывать не только код, но и содержание ответа, если API так устроен.

Примеры:

• `200 OK` + `success: true` — успешная обработка;

• `200 OK` + `error: validation failed` — технически запрос принят, но бизнес-ошибка осталась;

• `400 Bad Request` — неверные данные;

• `401 Unauthorized` — проблема с авторизацией;

• `429 Too Many Requests` — нужен повтор после паузы;

• `500 Internal Server Error` — временная ошибка сервера.

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

Шаг 6. Проверьте, были ли повторные попытки

Для временных ошибок должна быть видна цепочка:

1. первая попытка — ошибка;

2. пауза;

3. вторая попытка;

4. успешная доставка или финальная ошибка;

5. уведомление ответственному, если доставка не состоялась.

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

Как отличить сбой CRM от ошибки подрядчика

Ориентируйтесь на признаки:

• CRM не создала карточку — проверяйте источник заявки, форму, права доступа, лимиты CRM.

• Карточка создана, но webhook не появился в журнале — вероятна ошибка настройки события в CRM.

• Webhook отправлен, но payload неполный — ошибка маппинга полей или ТЗ.

• Payload полный, но внешний сервис вернул 400 — формат не соответствует API или не учтена валидация.

• Внешний сервис вернул 500/503 — возможно, временный сбой принимающей стороны, нужны ретраи.

• Была ошибка, но нет уведомления и повторной отправки — недоработка интеграционной логики.

• Все тесты успешны, но в пике появились HTTP 429 — не учтены лимиты API и нагрузка.

Важно: не принимайте объяснение «это разовый сбой», пока в логах не видно причину, время, код ответа и результат повторной попытки.

Какие SLA, ретраи и ответственность закрепить перед приёмкой

Перед оплатой нужно согласовать не только факт работы webhook, но и условия эксплуатации. Интеграция может пройти демонстрацию на одной заявке, но сломаться при реальном потоке, смене токена, обновлении CRM или недоступности внешнего сервиса.

Что закрепить в SLA

В SLA стоит указать:

• рабочие часы поддержки;

• время реакции на инцидент;

• время восстановления;

• каналы обращения;

• кто имеет право ставить задачи;

• какие ошибки считаются критическими;

• как фиксируется факт сбоя;

• какие логи используются как доказательство;

• срок хранения логов;

• гарантийный период.

Пример реалистичных условий для малого или среднего проекта:

• доступность интеграционного обработчика: 99–99,5% в месяц, если он размещён на стороне подрядчика;

• реакция на критический инцидент: до 2 часов в рабочее время;

• исправление критической ошибки: до 1 рабочего дня;

• хранение логов: не менее 30 дней;

• гарантия после приёмки: 14–30 дней;

• плановые доработки: по отдельной оценке в часах или фиксированной смете.

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

Какие ретраи прописать

Ретраи должны быть не «по возможности», а с понятным правилом:

• для HTTP 429 — повторить после паузы с учётом `Retry-After`, если он есть;

• для HTTP 500/502/503/504 — повторить 3–5 раз;

• для сетевого timeout — повторить по расписанию;

• для HTTP 400 — не повторять автоматически, а фиксировать ошибку данных;

• для HTTP 401/403 — уведомить ответственного, потому что нужен новый токен или права.

Хорошая схема: 1-я попытка сразу, 2-я через 1 минуту, 3-я через 5 минут, 4-я через 15 минут, 5-я через 60 минут. После финальной ошибки событие должно попасть в список ручной обработки, а не исчезнуть.

Что указать в акте приёмки

В акте не должно быть общей фразы «интеграция выполнена». Лучше перечислить проверенные сценарии:

• создание новой заявки;

• обновление статуса;

• назначение ответственного;

• обработка дубля;

• ошибка обязательного поля;

• неверный токен;

• timeout;

• HTTP 429;

• HTTP 500;

• повторная отправка;

• запись в логах;

• уведомление об ошибке;

• тест платёжного события, если оно есть.

Рядом укажите дату проверки, тестовые ID заявок и результат. Например: «Тестовая заявка CRM-TEST-014 от 28.04.2026: первая отправка получила HTTP 503, повторная через 5 минут завершилась HTTP 200, дубль не создан».

Как зафиксировать стоимость переделки

Отдельно пропишите, что входит в цену, а что считается новой задачей. Иначе после приёмки любое изменение формулируется как «доработка».

Разделите:

• исправление дефекта по ТЗ — бесплатно в гарантийный срок;

• изменение бизнес-логики — новая оценка;

• добавление нового webhook — отдельная задача;

• изменение полей из-за нового процесса — отдельная задача;

• перенос на другой сервис — отдельная смета;

• срочное исправление вне регламента — повышенный тариф, если согласован.

Типовые риски: нет ТЗ, размытые сроки, устные правки, скрытая стоимость материалов, неподходящий формат файлов или отсутствие поддержки. Для цифровой интеграции «материалы» — это доступы, API-ключи, документация CRM, примеры payload, тестовые аккаунты, файл маппинга полей и схема бизнес-процесса. Если этих данных нет, подрядчик может оценить работу неточно, а сроки 3–7 дней легко превратятся в две недели согласований.

Когда вебхуки CRM не подходят и что может пойти не так

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

Вебхуки не подходят, если нужна полная синхронизация истории

Webhook обычно сообщает о событии, а не передаёт всю базу. Если нужно перенести 50 000 клиентов, историю сделок за 3 года, комментарии, файлы и задачи, потребуется миграция через API, экспорт-импорт или ETL-процесс. Вебхуки здесь можно использовать позже — для новых изменений после первичной загрузки.

Вебхуки опасны без очереди

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

Вебхуки не заменяют бизнес-правила

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

Что может пойти не так после запуска

На практике чаще всего возникают такие проблемы:

• токен доступа истёк, а ответственный не назначен;

• CRM изменила название поля или ID поля;

• внешний сервис обновил API;

• менеджеры начали вручную менять статусы, которые запускают лишние события;

• рекламный трафик вырос, появились лимиты HTTP 429;

• логи хранятся только 7 дней, а проблему заметили позже;

• тестовые заявки попали в реальные отчёты;

• подрядчик не передал документацию;

• правки обсуждались устно и не вошли в гарантию;

• в payload передаются персональные данные без ограничения доступа.

Если хотя бы два-три риска уже видны до приёмки, не подписывайте акт без списка исправлений и сроков.

Сколько тестовых заявок нужно отправить перед приёмкой?

Минимум 10–15 заявок: успешная, без телефона, без email, дубль по телефону, дубль по email, неверный номер, длинный комментарий, ошибка авторизации, timeout, массовая отправка. Для платёжной интеграции добавьте успешную оплату, отмену и возврат.

Достаточно ли проверить один успешный webhook?

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

Какие логи просить у подрядчика?

Просите журнал с датой, временем, request_id, ID сделки, endpoint, HTTP-кодом, временем ответа, номером попытки и текстом ошибки. Для диагностики также полезны payload и response body, но персональные данные и токены должны быть замаскированы.

Что делать, если подрядчик не даёт доступ к логам?

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

Какие HTTP-коды обязательно проверить?

Минимум 200/201, 400, 401 или 403, 429 и 500. Если интеграция связана с оплатами или складом, проверьте также 409 для конфликтов и 504 для таймаутов шлюза.

Сколько ретраев должно быть у webhook?

Обычно достаточно 3–5 попыток с растущим интервалом: 1, 5, 15 и 60 минут. Для критичных событий можно добавить ручную очередь повторной отправки, чтобы администратор мог запустить событие после устранения причины.

Нужно ли подписывать акт, если остались мелкие ошибки?

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

Кто отвечает, если CRM была недоступна?

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

Что важнее: SLA или гарантия?

Это разные вещи. SLA описывает реакцию и восстановление во время эксплуатации, а гарантия — исправление дефектов после приёмки. Для вебхуков нужны оба условия.

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

Сравните ожидаемое правило с фактом. Если по ТЗ повторная заявка должна добавлять комментарий к существующему лиду, а CRM создала новую карточку без связи с первой, тест не пройден.

Можно ли принимать интеграцию без тестового контура?

Можно только для некритичных процессов и при явной маркировке тестовых заявок. Для оплат, заказов, клиентских уведомлений и массового трафика лучше использовать тестовую воронку, sandbox или отдельный endpoint.

Что включить в финальное письмо подрядчику перед оплатой?

Укажите список проверенных сценариев, ID тестовых заявок, найденные ошибки, сроки исправления, гарантийный период, SLA, порядок поддержки и сумму финальной оплаты. Чем конкретнее фиксация, тем меньше споров после запуска.