CMS и PHP
Интеграция API
Каждая интеграция — это точка, где ваш сайт становится зависим от чужой системы. Разбираем, как подключать внешние API так, чтобы сбой чужого сервиса не превращался в потерю заявок.
Интеграция API звучит как разовая техническая задача — «подключить», — но на практике это долгосрочные обязательства: чужой сервис может изменить формат ответа, стать временно недоступным или ограничить количество запросов. Хорошая интеграция проектируется с расчётом на то, что внешняя система однажды подведёт, и продумывает, что происходит в этот момент.
REST, вебхуки и разница в направлении данных
- REST API — ваш сайт сам запрашивает данные у внешнего сервиса по расписанию или по действию пользователя
- Вебхуки — внешний сервис сам присылает уведомление на ваш URL при событии (оплата прошла, статус заказа изменился)
- GraphQL — реже встречается в бизнес-интеграциях, но полезен, когда нужно гибко выбирать поля из большого объекта данных
- SDK-библиотеки — обёртка над REST/GraphQL от самого сервиса, ускоряет разработку, но добавляет зависимость от версии библиотеки
Авторизация: от API-ключа до OAuth 2.0
Простые интеграции (например, отправка SMS через сервис-провайдер) обходятся статичным API-ключом в заголовке запроса. Более серьёзные интеграции (доступ к данным пользователя через соцсеть, банковское API) используют OAuth 2.0 с временными токенами доступа и обновлением через refresh-токен. Ключевая ошибка новичков — хранить долгоживущие токены в коде или в открытом виде в базе, вместо шифрованного хранилища секретов.
- Получить учётные данные (API-ключ или OAuth client_id/secret) от провайдера
- Реализовать обмен на токен доступа и, если нужно, обновление токена по истечении срока
- Хранить секреты в переменных окружения или менеджере секретов, не в репозитории кода
- Логировать факт обращения к API (без самих секретов) для последующей диагностики сбоев
Обработка ошибок и повторные попытки
Внешний сервис может ответить с задержкой, вернуть 500-ю ошибку или временно быть недоступен из-за собственных технических работ. Интеграция без стратегии повторов в таком случае просто теряет данные — например, заявка клиента не долетает до CRM, и никто об этом не узнаёт, пока клиент не позвонит и не спросит, почему ему не ответили.
- Retry с экспоненциальной задержкой для временных ошибок (5xx, таймауты)
- Очередь с dead letter — если после N попыток запрос не прошёл, он не пропадает, а попадает в список для ручной проверки
- Разделение ошибок на временные (стоит повторить) и постоянные (неверные данные — повторять бессмысленно)
- Алерты, если процент ошибок по интеграции превышает нормальный порог
Идемпотентность: почему повтор запроса не должен дублировать данные
Если запрос на создание заказа отправлен дважды из-за сетевого сбоя и повторной попытки, результат должен остаться прежним — один заказ, а не два. Для этого используют идемпотентные ключи: уникальный идентификатор операции, который сервис проверяет перед выполнением, чтобы не обработать одно и то же действие повторно. Это особенно критично для платежных интеграций, где дублирование транзакции означает реальные финансовые потери.
Тестирование интеграций до релиза
- Использовать sandbox-окружение провайдера, если оно предусмотрено (у платёжных систем — почти всегда)
- Проверить сценарий сбоя: что происходит, если внешний сервис вернул ошибку или не ответил вовсе
- Проверить обработку неожиданного формата ответа — провайдер может изменить структуру данных без предупреждения
- Замерить время ответа интеграции под нагрузкой, если она в критическом пути (например, проверка остатков перед оплатой)
FAQ
Что делать, если внешний сервис часто меняет формат ответа без предупреждения?
Заложить строгую валидацию ответа с логированием несоответствий и алертом при первом же расхождении со схемой — так проблема обнаруживается сразу, а не через недели молчаливых сбоев.
Нужен ли отдельный слой между сайтом и внешним API?
Да, если интеграция сложная или используется в нескольких местах системы: прослойка (адаптер) изолирует специфику конкретного провайдера и упрощает его замену в будущем без переписывания бизнес-логики.
Как понять, что интеграция готова к продакшену?
Она обрабатывает не только успешный сценарий, но и таймауты, ошибки авторизации, лимиты запросов и неожиданные форматы ответа — и всё это протестировано, а не предполагается «на глаз».
Сколько стоит интеграция сайта с CRM?
Простая передача заявок через вебхук — от 10 000–15 000 ₽. Двусторонняя синхронизация статусов, клиентской базы и заказов — от 30 000 ₽ и выше, в зависимости от API конкретной CRM.
SEO-продвижение · Создание сайтов · Ещё в разделе «CMS и PHP»