No-code. Как самостоятельно связать сервисы по API и вебхукам без программиста, интеграций и сложных конструкторов

Всем привет, меня зовут Лаптев Алексей, я главный разработчик сервиса для всех интеграций ApiMonster. Сегодня расскажу принцип, как соединять любые сервисы, даже если нет готовой интеграции.

Проблема на рынке

Если связать условную Тильду и AmoCRM не составляет труда — есть десяток сервисов коннекторов.

То связать неизвестную CRM или самописный сервис с популярными сервисами уже сложнее, так как готовых интеграций нет и делать их никто не будет, так как ради 1-2 клиентов брать на себя поддержку интеграций не выгодно.

Решение

К счастью все сервисы общаются примерно одинаково — это get/post запросы со списком полей в формате json.

Примерно вот так:

Задача сводится к следующему: получить список полей и значений из сервиса А и закинуть в список полей и значений в сервис B.

Этим и занимаются все сервисы интеграций.

Для популярных сервисов создаются отдельные интеграции, где более понятно для клиента объясняется что нужно указать для доступа к сервису и какие поля можно задать.

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

Давайте разберемся как оно работает.

План связки двух любых сервисов

Рассмотрим на примере Тильды и AmoCRM, как наиболее понятные сервисы, но в место них можно подставить любой сервис.

1. Получить ссылку для вебхука для сервиса А.

  1. Подключаем интеграцию Входящий вебхук
  2. Получаем ссылку вида https://example.com/webhook/mAKYeNQ7QpKN04Z
  3. Вставляем ее в настройках вебхуков в сервисе А
  4. Указываем на какой триггер реагировать, обычно это создание/обновление сделки.

Примерно вот так:

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 есть коннектор или возможность написать свой под исходящий вебхук.

Можно ли сделать полноценный конструктор?

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

Потому что:

  1. Принять входящий вебхук и вытащить любые поля можно уже сейчас
  2. Отправить вебхук в самописный сервис, где есть возможность написать обработчик можно уже сейчас
  3. Делать конструктор интеграций для какой-нибуть amocrm нет смысла, так там сложный процесс модерации и программирования и проще заказать коннектор у сервиса.

Итого

95% задач по соединению сервисов решаются входящими/исходящими вебхуками и готовыми коннекторами в рамках любого сервиса.

Остальным не повезло — надо упрощать стек.

0
7 комментариев
Написать комментарий...
Maxim Filippov

Спасибо за статью;)

Ответить
Развернуть ветку
Vitaliy Nechaev
 Как самостоятельно связать сервисы по API и вебхукам без программиста, интеграций и сложных конструкторов

Интересно, а кто целевая аудитория продукта и статьи? 

Ответить
Развернуть ветку
Ivan Kozhin

А вот хрен знает, но программисты могут зайти улыбнуться

Ответить
Развернуть ветку
Александр Слепов

Пробовал я тут объединить Яндекс-формы и сервис рассылок Сендпульс. Нужно было настроить автописьмо при отправке формы с полем "Эл.почта". Навыки кодера и девопса у меня детские (и вообще лапки). Изучив апи, с json и http-запросами я вроде разобрался. Но в итоге оказалось, что Сендпульс, чтобы присвоить переменным в адресной книге значения из вне, требует указывать в запросе код доступа, который с некоторой (достаточно высокой) периодичностью у них автоматом меняется, и что с этим делать я так и не понял, а техподдержка обеих сторон развела руками - мол, не наша компетенция. Так этот эксперимент и закончился, и я пошел искать другие решения.

Ответить
Развернуть ветку
Alexey Laptev
Автор

Обычно код можно обновить через рефреш токен.

Там относительно сложный код, особенно если лапки.

Ответить
Развернуть ветку
Александр Слепов

Да в коде я бы разобрался в конце концов, знать бы только, как подобное решается в принципе (саму технологию)

Ответить
Развернуть ветку
Николай Полянский

Странно, что в поддержка Сендпульса вам не рассказала. Хотя возможно у них тоже "лапки". Как у амосрм последние два года: поддержка не даёт технических ответов, отсылает к "разработчикам интеграции", несмотря на то, что разработчик это я и есть, мне нужно было просто уточнить кое-что. Убрали с сайта "консоль разработчика", потом прикрыли авторизацию по ключу, а вскоре и тех. поддержка перестала на технические вопросы отвечать: у амо появились официальные представители, типа интеграторы, всё такое. А что, удобно: набрали клиентскую базу и бесплатно больше ответов не даём, не до этого. 

Ответить
Развернуть ветку
4 комментария
Раскрывать всегда