API-интеграция для собственного сайта: REST API, Webhook и способы подключения сторонних систем
1. WordPress REST API: сначала разберитесь в стандартных возможностях
Начиная с версии 4.7 в WordPress встроен REST API — плагины не нужны. Формат эндпоинта: https://ваш-домен/wp-json/wp/v2/posts. Откройте его в браузере — увидите список статей в формате JSON. По умолчанию этот API публичный: любой может читать ваши статьи, страницы и медиатеку. Это и плюс (удобно подключаться), и риск (внутренние данные открыты).
Для операций записи (создание статей, изменение заказов, добавление пользователей) нужна аутентификация. WordPress поддерживает два способа: Application Passwords (простой, генерируется на странице профиля пользователя, подходит для вызовов с собственного сервера) и OAuth 2.0 (сложный, подходит для авторизации сторонних приложений). Для подключения сайта к собственной CRM достаточно Application Passwords. Не храните логин и пароль admin жёстко в коде ради простоты.
Как решить: вам нужно читать данные из WordPress или записывать? Только чтение (список статей, записи заказов) — GET-запрос с Application Passwords. Запись (создание заказов, обновление пользователей, отправка Webhook) — POST/PUT-запросы, а права должны быть минимальными: например, только «редактирование заказов», без «управления всеми настройками». Как собрать стек — см.Технологический стек crater.
| Эндпоинт | Метод | Зачем нужен | Требования к сертификации |
|---|---|---|---|
| /wp-json/wp/v2/posts | GET | Чтение списка статей | Публичный (опубликованные) |
| /wp-json/wp/v2/posts | POST | Создание статьи | Application Passwords |
| /wp-json/wc/v3/orders | GET | Чтение заказов WooCommerce | Consumer Key |
| /wp-json/wc/v3/orders | POST | Создание заказа | Consumer Key |
| /wp-json/wp/v2/users | GET | Чтение списка пользователей | Пароль администратора |
| /wp-json/wp/v2/media | POST | Загрузка изображений | Редактирование указанных паролей |
2. Webhook: мгновенные уведомления по событиям
Webhook и REST API отличаются направлением. В REST вы сами идёте на сервер партнёра за данными, а Webhook — это когда сервер партнёра сам присылает данные вам, как только происходит событие. Например, когда в WooCommerce появляется новый заказ, он отправляет POST-запрос на URL, указанный в настройках Webhook, а в теле запроса — JSON с деталями заказа. Вам не нужно каждую минуту опрашивать «нет ли нового заказа» — заказ приходит автоматически.
WooCommerce поддерживает Webhook из коробки. Добавить его можно в WooCommerce → Настройки → Дополнительно → Webhooks. Нужно заполнить: событие-триггер (создание заказа, обновление заказа, отмена заказа), URL приёма (эндпоинт на вашем сервере, например https://ваш-домен/wp-json/custom/v1/new-order), способ подписи (HMAC-SHA256 — с помощью секретного ключа проверяется, что запрос действительно пришёл из WooCommerce, а не подделан кем-то другим).
Контринтуитивный вывод:Если Webhook не доставляется, вы, скорее всего, об этом даже не узнаете. Когда WooCommerce отправляет Webhook, а ваш сервер отвечает 500, он повторит попытку несколько раз (по умолчанию до 5 раз с увеличивающимся интервалом). Но если все 5 попыток провалятся, он сдаётся: вы не получаете ни данных, ни какого-либо уведомления. Поэтому критичные данные нельзя держать только на Webhook — нужен резервный механизм в виде периодического опроса. Как настроить интеграцию с CRM, читайте в разделе Интеграция CRM с собственным сайтом.
| Событие | Хук WooCommerce | Куда отправлять | Приоритет |
|---|---|---|---|
| Создание нового заказа | woocommerce_order_created | CRM + уведомление в Slack | Максимальная |
| Изменение статуса заказа | woocommerce_order_status_changed | Письмо клиенту + обновление в CRM | Высокий |
| Успешная оплата | woocommerce_payment_complete | Обновление в системе лояльности | Высокий |
| Оформление возврата | woocommerce_order_refunded | Отметка в CRM + уведомление в бухгалтерию | Средний |
| Регистрация нового пользователя | user_register | Список для email-рассылки | Средний |
| Публикация/снятие товара с публикации | woocommerce_product_set_visibility | Синхронизация со складской системой | Низкая |
III. Периодический опрос через REST: сверка как страховка
Webhook отвечает за мгновенные уведомления, но вам обязательно нужен ещё один слой — периодический опрос для сверки. Делается это просто: пишете скрипт на WP-Cron, который запускается раз в час, обращается к WooCommerce REST API и забирает заказы, созданные или обновлённые за последний час, а затем сравнивает их с теми, что уже есть в вашей базе. Если Webhook пропустил какой-то заказ (например, ваш сервер в момент отправки вернул 502), периодический опрос его подтянет.
В параметрах запроса при периодическом опросе нужно передавать метку времени. Например, GET /wp-json/wc/v3/orders?after=2026-09-21T10:00:00&per_page=100 вернёт все заказы после 10:00, по 100 штук на страницу. Если вернулось 100 записей, значит, скорее всего, есть ещё — продолжайте листать страницы. После этого удалите дубликаты по ID заказа: то, что уже есть в базе, пропускаете, новое вставляете. Это и есть простейшая логика сверки.
Пример: в среду в 15:00 SSL-сертификат сервера истёк и вернул 525 на 40 минут. За это время вебхуки трёх новых заказов не прошли. Если бы был только вебхук, эти три заказа потерялись бы. Но настроена почасовая выгрузка: в 16:00 она подхватила пропущенные заказы, и клиенты получили письма с подтверждением. Как настроить мониторинг, см.Мониторинг сайта и оповещения.
| Способ синхронизации | Частота | Задержка | Действия при сбое |
|---|---|---|---|
| Вебхук-уведомления | По событию | Секунды | Партнёр сдаётся после 5 попыток |
| Почасовая выгрузка | Каждый час ровно | Минуты | При сбое повторит в следующий раз |
| Ежедневная сверка всех данных | Каждый день в 3 часа ночи | Дни | Отчёт о расхождениях проверяет человек |
| WebSocket в реальном времени | В реальном времени | Миллисекунды | При обрыве нужно переподключение |
Четыре. Аутентификация и безопасность: ключ на бэкенде, подпись запроса
Самая частая ошибка в безопасности при интеграции по API — хранить API-ключ в клиентском JavaScript. Любой откроет в браузере F12 → вкладку Network и увидит ваш ключ, а потом будет дёргать ваш API сколько угодно. Правильно так: фронтенд обращается только к вашему серверу, а сервер добавляет API-ключ и пересылает запрос третьей стороне. Таким прокси на бэкенде может быть пользовательский REST-эндпоинт WordPress или простой сервис на Node.js/Python.
Принимая вебхук, обязательно проверяйте подпись. WooCommerce при отправке вебхука добавляет в HTTP-заголовки X-WC-Webhook-Signature — это подпись HMAC-SHA256, посчитанная по телу запроса с вашим Webhook Secret. Вы считаете такую же подпись на своём эндпоинте и сравниваете с заголовком: совпало — обрабатываете. Не совпало — запрос подделан, сразу возвращайте 403. Без проверки подписи любой может отправить POST с фальшивым заказом на ваш эндпоинт, и в CRM посыплются мусорные лиды.
Пример: вы принимаете вебхуки HubSpot, и кто-то узнал ваш URL. Он отправляет POST с фальшивым «новым лидом». Без проверки подписи этот лид попадёт в HubSpot, продавец будет вести его полдня, а потом выяснит, что он ненастоящий. С проверкой HMAC запрос HubSpot приходит с верной подписью, а у поддельного подпись не сходится — его сразу отсекает 403. Подробности интеграции с CRM см.Интеграция CRM с собственным сайтом.
| Пункт безопасности | Неправильный подход | Правильный подход |
|---|---|---|
| Где хранится API-ключ | В клиентском JS | В переменных окружения на сервере |
| Проксирование запросов | Фронтенд обращается к API третьей стороны напрямую | Фронтенд обращается к своему серверу, бэкенд пересылает |
| Проверка подписи вебхука | Без проверки, обрабатываем как есть | Сравнение HMAC-SHA256 с заголовком |
| HTTPS | Приём вебхуков по HTTP | Только HTTPS, TLS 1.2 и выше |
| Белый список IP | Без ограничений по IP источника | Белый список по официальным диапазонам IP партнёра |
| Логи ошибок | При сбое ничего не записывается | Все ответы вне 2xx пишутся в лог |
Пять. Список частых интеграций с третьими сторонами
В независимом магазине обычно пять типов сторонних интеграций: CRM (HubSpot, Salesforce, Zoho), email-маркетинг (Mailchimp, ConvertKit, Klaviyo), платёжные шлюзы (Stripe, PayPal), аналитика (Google Analytics 4, Hotjar) и поддержка клиентов (Intercom, Zendesk). Способ подключения у каждого свой, но принцип один: где можно — Webhook (в реальном времени), а для ключевых данных добавьте периодическую выгрузку как страховку.
Не бросайтесь сразу писать код для интеграции. Сначала проверьте, нет ли готового плагина в каталоге WordPress: у HubSpot есть официальный плагин, у Mailchimp — официальный, у Stripe — официальное расширение для WooCommerce. Готовые плагины закрывают 80% задач, а оставшиеся 20% (например, маппинг кастомных полей) добираются через Webhook или собственный код. Написать интеграцию двух систем самому — это обычно больше 20 часов отладки, а установка готового плагина занимает час. Как выбрать CRM-плагин, читайте в Заявки с сайта в CRM.
| Тип системы | Рекомендуемый подход | Способ интеграции | Ожидаемые трудозатраты |
|---|---|---|---|
| CRM (HubSpot) | Официальный плагин + Webhook | Плагин синхронизирует автоматически | 2–4 часа |
| Email-маркетинг (Mailchimp) | Официальный плагин | Регистрация автоматически добавляет в список | 1–2 часа |
| Оплата (Stripe) | Официальное расширение WooCommerce | Webhook синхронизирует статус заказа | 1–2 часа |
| Аналитика (GA4) | Плагин Site Kit by Google | Автоматическая разметка на фронтенде | 30 минут |
| Поддержка (Intercom) | Официальный плагин чата | Сниппет кода на фронтенде | 30 минут |
| Собственная ERP | Своя интеграция через REST | Периодическая выгрузка + Webhook | Больше 20 часов |
FAQ: частые вопросы
Чем REST API отличается от Webhook и что лучше?
Нужен ли плагин для WordPress REST API?
Где хранить API Key и можно ли использовать его на фронтенде?
Как убедиться, что запрос на приёмник Webhook настоящий?
Что делать, если Webhook не доставился?
Для интеграции со сторонней системой брать готовый плагин или писать самому?
В заключение
В интеграции по API важна не сложность, а надёжность. Цель одна: данные не теряются, статусы верные, при сбое есть где посмотреть. Webhook быстрый, но ненадёжный, REST медленный, но управляемый — только вместе они дают продакшен-решение. Любой из них по отдельности рано или поздно приведёт к потере данных.
Три шага к внедрению: для ключевых интеграций ставьте Webhook с уведомлениями в реальном времени и проверкой HMAC на приёмнике; добавьте ежечасный REST-запрос по расписанию для сверки — он автоматически подтянет пропущенное; все API Key держите в переменных окружения на бэкенде, а фронтенд пусть обращается только к прокси на вашем сервере.
Одна фраза, которую стоит запомнить: Webhook — это «мгновенное уведомление», REST — «регулярная сверка». Полагаться только на уведомления и не сверяться — всё равно что слышать звонок в дверь и не проверять почтовый ящик.