No-code. Как самостоятельно связать сервисы по API и вебхукам без программиста, интеграций и сложных конструкторов
Всем привет, меня зовут Лаптев Алексей, я главный разработчик сервиса для всех интеграций ApiMonster. Сегодня расскажу принцип, как соединять любые сервисы, даже если нет готовой интеграции.
Проблема на рынке
Если связать условную Тильду и AmoCRM не составляет труда — есть десяток сервисов коннекторов.
То связать неизвестную CRM или самописный сервис с популярными сервисами уже сложнее, так как готовых интеграций нет и делать их никто не будет, так как ради 1-2 клиентов брать на себя поддержку интеграций не выгодно.
Решение
К счастью все сервисы общаются примерно одинаково — это get/post запросы со списком полей в формате json.
Примерно вот так:
Задача сводится к следующему: получить список полей и значений из сервиса А и закинуть в список полей и значений в сервис B.
Этим и занимаются все сервисы интеграций.
Для популярных сервисов создаются отдельные интеграции, где более понятно для клиента объясняется что нужно указать для доступа к сервису и какие поля можно задать.
Но в целом все можно решить парочкой универсальных интеграций — это входящий вебхук и исходящий вебхук.
Давайте разберемся как оно работает.
План связки двух любых сервисов
Рассмотрим на примере Тильды и AmoCRM, как наиболее понятные сервисы, но в место них можно подставить любой сервис.
1. Получить ссылку для вебхука для сервиса А.
- Подключаем интеграцию Входящий вебхук
- Получаем ссылку вида https://example.com/webhook/mAKYeNQ7QpKN04Z
- Вставляем ее в настройках вебхуков в сервисе А
- Указываем на какой триггер реагировать, обычно это создание/обновление сделки.
Примерно вот так:
2. Вебхуки начинают поступать
Можно посмотреть что там пришло и какие поля есть, но пока данные никуда не уходят.
Вебхук выглядит примерно так:
3. Настраиваем исходящий вебхук и маппинг
Подключаем интеграцию, которая посылает post запрос на внешний url, примерно вот такую.
Настраивает маппинг, где говорим сервису:
- Передавай поле email из сервиса A в поле email сервиса B
- Передавай поле phone из сервиса А в поле email сервиса B
4. Формируется массив данных и отправляется запрос в указанный url
Согласно маппингу формируется json опять же примерно вот так:
И отправляется Post запросом на указанный url.
5. В сервисе «B» принимается запрос и выполняется нужное действие
Обычно создание сделки.
Если у вас самопис, то просто забирается данные из post-запроса и делаете что вам нужно.
Сложности и ограничения
Это все прекрасно работает, когда сервис А посылает сразу все данные в вебхуке и сервис B также готов принять массив данных без сложностей без каких либо сложностей.
Входящие вебхуки
Сервис А должен в вебхуке передавать полный набор данных, без необходимости запрашивать уточнения по id, как это происходит в Bitrix24 или RetailCRM.
Хороший пример — Тильда.
Исходящие вебхуки
Тут сложнее.
Сервис «B» должен уметь принимать массив данных в Json по указанному url, но обычно это умеют только самописные решения.
У популярных сервисов сложная механика доступов и API, просто так запрос не пошлешь, нужно пилить интеграцию, решая все эти проблемы.
В таких интеграция и есть ценность сервисов-коннекторов, местами там совсем не тривиально.
Но в целом тут нет проблемы, так как основная задача это — соединить малоизвестный сервис с популярным, где с приемом вебхука их сервиса А нет проблем, а на популярные сервисы B есть коннектор или возможность написать свой под исходящий вебхук.
Можно ли сделать полноценный конструктор?
Некоторые сервисы пытаются их делать, но я не вижу особого смысла идти дальше возможности принять и отправить универсальный вебхук.
Потому что:
- Принять входящий вебхук и вытащить любые поля можно уже сейчас
- Отправить вебхук в самописный сервис, где есть возможность написать обработчик можно уже сейчас
- Делать конструктор интеграций для какой-нибуть amocrm нет смысла, так там сложный процесс модерации и программирования и проще заказать коннектор у сервиса.
Итого
95% задач по соединению сервисов решаются входящими/исходящими вебхуками и готовыми коннекторами в рамках любого сервиса.
Остальным не повезло — надо упрощать стек.
Спасибо за статью;)
Интересно, а кто целевая аудитория продукта и статьи?
А вот хрен знает, но программисты могут зайти улыбнуться
Пробовал я тут объединить Яндекс-формы и сервис рассылок Сендпульс. Нужно было настроить автописьмо при отправке формы с полем "Эл.почта". Навыки кодера и девопса у меня детские (и вообще лапки). Изучив апи, с json и http-запросами я вроде разобрался. Но в итоге оказалось, что Сендпульс, чтобы присвоить переменным в адресной книге значения из вне, требует указывать в запросе код доступа, который с некоторой (достаточно высокой) периодичностью у них автоматом меняется, и что с этим делать я так и не понял, а техподдержка обеих сторон развела руками - мол, не наша компетенция. Так этот эксперимент и закончился, и я пошел искать другие решения.
Обычно код можно обновить через рефреш токен.
Там относительно сложный код, особенно если лапки.
Да в коде я бы разобрался в конце концов, знать бы только, как подобное решается в принципе (саму технологию)
Странно, что в поддержка Сендпульса вам не рассказала. Хотя возможно у них тоже "лапки". Как у амосрм последние два года: поддержка не даёт технических ответов, отсылает к "разработчикам интеграции", несмотря на то, что разработчик это я и есть, мне нужно было просто уточнить кое-что. Убрали с сайта "консоль разработчика", потом прикрыли авторизацию по ключу, а вскоре и тех. поддержка перестала на технические вопросы отвечать: у амо появились официальные представители, типа интеграторы, всё такое. А что, удобно: набрали клиентскую базу и бесплатно больше ответов не даём, не до этого.