Интеграция WordPress с CRM через REST API и webhooks: архитектура без потери заявок

Интеграция WordPress с CRM выглядит простой только в идеальном сценарии: посетитель отправил форму, сайт сделал HTTP-запрос, CRM создала лид. В реальной работе появляются таймауты, повторные клики, временные ошибки API, изменённые поля, webhooks и необходимость понять через неделю, куда исчезла конкретная заявка.

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

Что даёт REST API WordPress

WordPress REST API позволяет приложениям обмениваться с сайтом JSON-данными по HTTP. В ядре есть маршруты для стандартных сущностей, а плагин может регистрировать собственные endpoints с отдельными callback и permission_callback.

Для интеграции с CRM это удобно в обе стороны: внешний сервис может безопасно обращаться к разрешённым endpoint сайта, а WordPress через HTTP API может отправлять данные во внешнюю систему.

REST API и webhook решают разные задачи

Часто рабочая схема использует оба механизма. WordPress отправляет новую заявку через API, а CRM возвращает изменения статуса через webhook.

Правильный путь заявки

1. Пользователь отправляет форму.
2. WordPress валидирует обязательные поля.
3. Заявка получает внутренний идентификатор.
4. Данные сохраняются локально до внешнего запроса.
5. Интеграционный слой отправляет payload в CRM.
6. Ответ CRM сохраняется вместе с внешним ID.
7. При временной ошибке задача уходит на повтор.
8. После успеха заявка помечается синхронизированной.

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

Почему нельзя отправлять только из frontend JavaScript

Если браузер напрямую отправляет важную заявку во внешнюю CRM, закрытие вкладки, блокировка запроса или ошибка JavaScript может оборвать процесс. Кроме того, секреты внешнего API нельзя безопасно хранить в публичном frontend-коде.

Критичную передачу лучше выполнять на серверной стороне WordPress или через отдельный backend/automation layer.

Idempotency защищает от дублей

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

Если CRM поддерживает внешний идентификатор или idempotency key, его стоит использовать. Если нет, связь можно хранить у себя: внутренний ID заявки → внешний ID CRM.

Какие ошибки нужно повторять

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

• network timeout — повтор с задержкой;
• HTTP 5xx — ограниченные повторы;
• rate limit — повтор по правилам API;
• HTTP 4xx из-за данных — лог и ручная проверка;
• ошибка авторизации — остановка очереди и уведомление администратору.

Что логировать

Лог интеграции нужен не ради гигабайтов текста. Для диагностики достаточно фиксировать внутренний ID, время, тип события, endpoint, код ответа, внешний ID и короткое описание ошибки. Токены, пароли и лишние персональные данные в лог писать нельзя.

Хороший журнал позволяет ответить на вопрос: заявка была принята сайтом, отправлена, повторена, создана в CRM или остановилась на конкретной ошибке?

Webhook от CRM: что проверять

Webhook — входящий запрос из внешней системы. Endpoint должен проверять предусмотренный провайдером механизм подлинности, валидировать payload и права операции. Повторная доставка одного события не должна повторно выполнять необратимое действие.

После приёма тяжёлую обработку лучше отделять от быстрого HTTP-ответа, если CRM требует короткий timeout.

Сопоставление полей

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

Где размещать код интеграции

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

Подробнее такой подход описан на странице разработки плагинов WordPress.

Когда нужен отдельный backend

Для одной формы и одной CRM отдельный сервис может быть лишним. Но если есть несколько сайтов, много событий, очереди, разные CRM, Telegram, email и AI-обработка, интеграционный слой разумно вынести из WordPress. Тогда сайт остаётся источником заявок, а маршрутизация выполняется отдельно.

Подобные процессы относятся к автоматизации бизнеса и могут развиваться постепенно.

Чек-лист перед запуском

• форма сохраняет заявку до внешней отправки;
• секреты находятся только на сервере;
• есть стабильный ID события;
• повторы не создают дубль;
• 4xx и 5xx обрабатываются по-разному;
• webhook проверяет подлинность;
• логи не содержат секретов;
• есть уведомление о критической ошибке;
• проверен тестовый и production endpoint;
• известно, где искать заявку при сбое.

Что нужно для оценки интеграции

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

Если нужна доработка существующего сайта, можно также посмотреть услуги WordPress-разработчика или отправить задачу через контакты A.S Groups.

FAQ

Можно ли подключить CRM без готового плагина?

Да. Если у CRM есть подходящий API, интеграцию можно реализовать отдельным WordPress-плагином под конкретный процесс.

Что делать, если CRM временно недоступна?

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

Почему появляются дубли лидов?

Обычно из-за повторной отправки формы, сетевых повторов или webhook без idempotency. Нужен стабильный идентификатор операции.

Можно ли передавать UTM-метки?

Да. Их можно сохранить вместе с заявкой и передать в отдельные поля CRM, если такие поля предусмотрены.

Нужен ли Make или n8n?

Не обязательно. Для простой связки достаточно прямого API. Automation-платформа полезна, когда процесс связывает несколько систем и его нужно часто менять без доработки основного сайта.