Вебхуки позволяют интернет-магазину автоматически передавать события между сайтом, CRM, службой доставки и SMS-шлюзом. Когда клиент оформил заказ, посылка прибыла в пункт выдачи или доставка задержалась, система отправляет уведомление без ручной обработки. В статье разберём простую схему интеграции через API, список нужных событий, защиту от дублей и проверку ошибок. В результате можно собрать понятную SMS-цепочку, которую легко контролировать даже небольшой команде.
Что такое вебхук и зачем он нужен интернет-магазину?
Вебхук — это автоматическое сообщение от одной системы к другой. Интернет-магазин сообщает CRM, что появился новый заказ, CRM передаёт событие в сервис уведомлений, а служба доставки возвращает новый статус посылки. Каждая система реагирует на конкретное событие, поэтому оператору не приходится переносить данные вручную.
Обычный пример выглядит так: покупатель оплатил заказ на сайте. Магазин отправляет вебхук с номером заказа, телефоном клиента и текущим статусом. Сервис SMS подставляет данные в шаблон и передаёт сообщение оператору связи. После этого в CRM сохраняется результат отправки.
Автоматизация SMS-рассылок обычно строится именно на связке CRM, e-commerce-платформы или другого рабочего сервиса с SMS-шлюзом через API. Такой подход используют для подтверждения заказа, изменения его статуса, напоминания о доставке и других событий, которые запускаются по правилу. Подробнее о логике таких цепочек можно прочитать в материале как настроить SMS-цепочку статуса заказа.
Какие системы нужно соединить через API?
Перед настройкой разделите процесс на четыре части. Это помогает понять, где возникает ошибка и какая система отвечает за конкретные данные.
- Интернет-магазин фиксирует заказ, оплату, отмену и возврат.
- CRM хранит карточку клиента, историю общения и статус обработки.
- Служба доставки сообщает о передаче отправления, прибытии и задержке.
- SMS-шлюз принимает запрос, отправляет сообщение и возвращает технический статус.
Не обязательно соединять все системы напрямую. Для малого магазина часто достаточно передавать из сайта в CRM только номер заказа и его статус, а CRM уже отправляет запрос в SMS-сервис. Если служба доставки имеет API, она может обновлять статус в CRM отдельным вебхуком.
До начала работ составьте таблицу событий. В ней должны быть понятные названия, источник события и действие после получения запроса.
| Событие | Источник | Действие | Пример SMS |
|---|---|---|---|
| Заказ создан | Интернет-магазин | Подтвердить получение заказа | «Заказ №{{номер}} принят. Мы сообщим о следующем статусе.» |
| Оплата подтверждена | Магазин или CRM | Сообщить о начале обработки | «Оплата заказа №{{номер}} получена. Заказ передан в обработку.» |
| Отправление передано в доставку | CRM или служба доставки | Отправить трек-номер | «Заказ №{{номер}} передан в доставку. Номер отправления: {{трек}}.» |
| Прибытие в пункт выдачи | Служба доставки | Напомнить о получении | «Заказ №{{номер}} прибыл. Получите его по адресу: {{адрес}}.» |
| Задержка доставки | Служба доставки | Предупредить клиента | «Доставка заказа №{{номер}} задерживается. Новый срок: {{дата}}.» |
| Возврат или отмена | Магазин или CRM | Сообщить об изменении заказа | «Заказ №{{номер}} отменён. По вопросу возврата средств свяжитесь с магазином.» |
Как выглядит вебхук для SMS-уведомления?
Технически вебхук — это HTTP-запрос с данными о событии. Внутри обычно передают идентификатор заказа, телефон клиента, название события, текст или код шаблона. Для магазина лучше передавать именно код шаблона, а не готовый текст: тогда содержание SMS можно изменить в одном месте.
Условная структура события может выглядеть так:
- event: order_ready;
- order_id: 4821;
- phone: номер клиента;
- pickup_address: адрес пункта выдачи;
- message_template: pickup_ready;
- event_id: уникальный идентификатор события.
Поле event_id нужно для защиты от повторной отправки. Система доставки иногда повторяет запрос, если не получила ответ вовремя. Если CRM или SMS-шлюз не проверит идентификатор, клиент может получить два одинаковых сообщения. Для таких ситуаций полезен отдельный разбор почему SMS отправляется дважды и как защитить API от дублей.
После обработки запроса принимающая система должна вернуть понятный ответ. Успешный запрос получает статус 200, а временная ошибка должна привести к повторной попытке. При постоянной ошибке событие лучше отправить в журнал, чтобы сотрудник мог проверить его вручную.
Как настроить интеграцию по шагам?
- Опишите путь заказа. Запишите, где рождается каждое событие и какая система должна его получить. Например, сайт создаёт заказ, CRM подтверждает оплату, служба доставки меняет статус.
- Выберите обязательные SMS. Для старта хватит подтверждения заказа, передачи в доставку, прибытия и задержки. Не отправляйте сообщение на каждое внутреннее изменение статуса.
- Создайте шаблоны. В каждом тексте оставьте номер заказа и конкретное действие для клиента. Если сообщение связано с доставкой, добавьте адрес, дату или трек-номер.
- Настройте адрес вебхука. Система-источник должна знать URL приёмника, формат запроса и способ авторизации. Эти параметры берут из документации API сервиса, который принимает события.
- Добавьте проверку повторов. Сохраняйте event_id и не отправляйте второе SMS, если такое событие уже обработано.
- Настройте журнал. Записывайте время запроса, событие, номер заказа, ответ API и статус SMS. Телефон в отчёте лучше показывать частично, чтобы оператор мог отличить клиента без лишнего раскрытия данных.
- Проведите тесты. Проверьте успешную отправку, неверный номер заказа, временную недоступность системы и повтор одного и того же вебхука.
Если магазин работает на готовой CMS, часть событий можно настроить модулем. Для нестандартной логики потребуется небольшая интеграция: разработчик принимает вебхук, сопоставляет поля и передаёт запрос в SMS API. Для владельца бизнеса это обычно означает подготовить карту событий, шаблоны и правила повторной отправки.
Как контролировать доставку и искать ошибки?
Одного факта отправки API-запроса недостаточно. Магазин должен различать несколько этапов: событие создано, запрос принят, SMS передано шлюзу, сообщение доставлено или завершилось ошибкой. Иначе оператор увидит в CRM статус «отправлено», хотя телефон клиента был недоступен.
| Что проверить | Возможная причина | Действие |
|---|---|---|
| Вебхук не пришёл | Ошибка адреса или доступа | Проверить URL, авторизацию и журнал запросов |
| Пришёл неполный запрос | Не совпали названия полей | Сверить формат данных сайта и приёмника |
| SMS не создано | Не найден шаблон или номер заказа | Проверить обязательные поля и подстановки |
| SMS отправлено дважды | Нет защиты от повторного event_id | Добавить проверку уже обработанных событий |
| Статус не обновился | CRM не приняла ответ службы доставки | Проверить код ответа и повторить запрос по правилу |
Мониторинг полезен даже небольшому магазину. В отчёте достаточно видеть количество событий, успешные запросы, ошибки API и статусы доставки SMS. Если уведомления перестали уходить, владелец узнает об этом до того, как сотрудники начнут получать вопросы о заказах. Для такой задачи подходит отдельный подход к мониторингу транзакционных SMS без программиста.
Какие ошибки чаще всего мешают интеграции?
- Все статусы запускают SMS. Внутренние изменения заказа не всегда нужны клиенту. Оставьте только события, которые меняют его ожидания или требуют действия.
- Текст собирается в нескольких системах. Из-за этого разные сотрудники меняют шаблоны по-разному. Храните тексты в одном сервисе и передавайте через API код нужного шаблона.
- Нет уникального идентификатора. Повтор вебхука воспринимается как новое событие, поэтому клиент получает дубликат.
- Ошибки не записываются. Без журнала трудно определить, где исчез заказ: на сайте, в CRM, у службы доставки или в SMS-шлюзе.
- Тестируют только удачный сценарий. Проверьте задержку ответа, отмену заказа, повтор запроса и отсутствие обязательного поля.
Вебхуки связывают магазин, CRM и доставку вокруг событий заказа. Начните с четырёх уведомлений, задайте единый формат данных и добавьте журнал обработки. Затем подключите повторные попытки и защиту от дублей. Если интеграция должна учитывать нестандартные статусы или несколько служб доставки, её можно собрать через SMS API с мониторингом и отчётностью под процессы конкретного магазина.
