05.03
Как сервисы связываются: API, webhooks, triggers и actions
РЕЗУЛЬТАТ УРОКА
Понимать, как события и данные проходят между сервисами.Главное за 30 секунд
API позволяет одному сервису запросить действие у другого; webhook сообщает о событии; trigger начинает сценарий, action выполняет работу.
Разбираемся
Автоматизация — это всегда обмен данными между сервисами. Telegram говорит CRM: «пришла заявка». CRM говорит AI: «вот данные, классифицируй». AI говорит CRM: «вот результат». Понимать, как работают эти разговоры, не нужно на уровне программиста — но нужно достаточно, чтобы проектировать надёжные сценарии и понимать, где что может сломаться.
API простыми словами
API — это договор между сервисами о том, как они общаются. Один сервис отправляет запрос: «создай контакт с такими данными». Другой выполняет и отвечает: «готово, вот ID» или «ошибка: поле телефон обязательно». Если API есть — сервисы можно соединить. Если нет — нужен обходной путь или другой инструмент.
Request и response
Каждое обращение к API состоит из запроса (request) и ответа (response). Запрос содержит: что делать, с какими данными, с каким ключом авторизации. Ответ содержит: результат или код ошибки. Автоматизация должна обрабатывать оба варианта — успех и ошибку.
Webhooks
Webhook — это «обратный звонок»: вместо того чтобы постоянно спрашивать «есть что-то новое?», сервис сам сообщает вам, когда что-то произошло. «Пришла новая форма» — webhook отправляет данные на ваш адрес мгновенно. Это эффективнее и быстрее, чем периодический опрос.
Triggers и actions
В платформах автоматизации (n8n, Make и аналогах) trigger — событие, которое запускает сценарий. Action — что происходит в ответ. Одному trigger'у может соответствовать несколько последовательных или параллельных actions. Понимание этой пары достаточно, чтобы читать и строить большинство сценариев.
1. Счастливый путь
Главное: планировать нужно не путь «всё получилось», а поведение при недоступности — именно он отличает интеграцию от демонстрации.
Аутентификация и безопасность
API-ключи, токены и OAuth — это способы сервисов проверять, кто к ним обращается. Никогда не храните ключи в открытом виде в коде, таблицах или сообщениях. Используйте переменные окружения или защищённые хранилища. Скомпрометированный ключ — это несанкционированный доступ к вашим данным и действиям.
ПРИМЕР
Связали два сервиса, потеряли половину заявок
Ситуация. CRM и сайт связаны через вебхук: новая заявка сразу создаёт сделку. Проверили на десяти заявках — работает.
Результат. Через неделю в CRM оказалось на 40% меньше сделок, чем заявок на сайте: при недоступности CRM сервис отправлял вебхук один раз и терял его без следа. Повторная отправка при ошибке и журнал доставленных событий — стандартная часть такой связки, но их не заказывали, потому что на тестах ошибок не было.
ПРАКТИКА
Сделайте сейчас
Возьмите один сценарий, который хотите автоматизировать. Опишите обмен данными между двумя-тремя сервисами в формате: кто отправляет, что именно, кому, что происходит при успехе, что при ошибке. Это ваш первый API-контракт — без кода, только логика. Проверьте: если один из сервисов недоступен — что происходит с данными?
ОГРАНИЧЕНИЯ
Где нужен человек
- Нельзя передавать API-ключи в сообщениях, таблицах или клиентском коде — только в защищённых хранилищах.
- Каждая интеграция — потенциальная точка отказа: планируйте обработку ошибок заранее.
Ещё на уровне 05
Материал проверен: 20 августа 2026. Инструменты и тарифы меняются — сверяйтесь с первоисточником.