Битрикс24
February 7, 2023

Смена этапа сделки в Битрикс24 внешними инструментами. Часть 2

Обследуем Битрикс24 через REST API

Сервисы

В рамках цикла статей об управлении Битрикс24 с помощью внешних сервисов (Salebot, n8n), хочу написать про подручные средства, которые сильно помогают в подготовительных действиях. Или когда нужно быстро что-то проверить.

Postman - помогает формировать и отправлять http-запросы к любому веб-сервису, имеющему лазейку в виде REST API. Например, увидеть значение полей карточки сделки, карточки клиента итп в Битрикс24. Также с помощью таких запросов можно делать изменения данных в рамках дозволенного. То есть, входящие веб-хуки Битрикс24 анализируем Postman-ом (запрос исходит из Postman-а и входит в Битрикс24).

Webhook.site - помогает отлавливать веб-хуки: запросы-сигналы веб-сервисов, отправляемые во внешний мир, о каких-либо событиях, происходящих в этих сервисах. Например, создание сделки, клиента или пользователя CRM, завершение сделки итп. Этот сервис предоставляет адрес для обработки, который мы указываем в исходящих веб-хуках. То есть, для исходящих веб-хуков Битрикс24 подставляем персональный адрес из сервиса Webhook.site.

JSON Editor Online - анализатор наборов данных в формате JSON. Обычно сервисы "отдают" данные в трудночитаемом виде. JSON Editor Online приводит такой набор данных в удобный для понимания вид.

Подготовка

В предыдущем шаге мы подготовили несколько входящих веб-хуков. В частности, просмотр сделки, редактирование сделки.

Попробуем с помощью входящего веб-хука просмотреть поля сделки

Возьмём тестовую воронку, состоящую из трёх этапов

Тестовая сделка №185:

В сервисе Postman формируем get-запрос с помощью метода crm.deal.get:

___ - замена api-key Битрикс24 для скриншота из соображений безопасности

?id=185 - указываем, данные какой сделки мы запрашиваем.

Получаем следующий JSON-набор данных

{
"result": {
"ID": "185",
"TITLE": "Николай Васильев - Линия для подключения Salebot.pro",
"TYPE_ID": null,
"STAGE_ID": "C1:NEW",
"PROBABILITY": null,
"CURRENCY_ID": "RUB",
"OPPORTUNITY": null,
"IS_MANUAL_OPPORTUNITY": "N",
"TAX_VALUE": null,
"LEAD_ID": null,
"COMPANY_ID": "0",
"CONTACT_ID": "23",
"QUOTE_ID": null,
"BEGINDATE": "2022-12-26T03:00:00+03:00",
"CLOSEDATE": "",
"ASSIGNED_BY_ID": "1",
"CREATED_BY_ID": "1",
"MODIFY_BY_ID": "1",
"DATE_CREATE": "2022-12-26T16:35:46+03:00",
"DATE_MODIFY": "2022-12-26T16:35:46+03:00",
"OPENED": "Y",
"CLOSED": "N",
"COMMENTS": null,
"ADDITIONAL_INFO": null,
"LOCATION_ID": null,
"CATEGORY_ID": "1",
"STAGE_SEMANTIC_ID": "P",
"IS_NEW": "Y",
"IS_RECURRING": "N",
"IS_RETURN_CUSTOMER": "N",
"IS_REPEATED_APPROACH": "N",
"SOURCE_ID": "9|SALEBOT_CONNECTOR",
"SOURCE_DESCRIPTION": null,
"ORIGINATOR_ID": null,
"ORIGIN_ID": null,
"MOVED_BY_ID": "1",
"MOVED_TIME": "2022-12-26T16:35:45+03:00",
"UTM_SOURCE": null,
"UTM_MEDIUM": null,
"UTM_CAMPAIGN": null,
"UTM_CONTENT": null,
"UTM_TERM": null,
"LAST_ACTIVITY_BY": "1",
"LAST_ACTIVITY_TIME": "2022-12-26T16:35:46+03:00",
},
"time": {
"start": 1675790731.4939001,
"finish": 1675790731.6215391,
"duration": 0.1276390552520752,
"processing": 0.046903133392333984,
"date_start": "2023-02-07T20:25:31+03:00",
"date_finish": "2023-02-07T20:25:31+03:00",
"operating_reset_at": 1675791331,
"operating": 0
}
}

Получили кучу всего. На данный момент нас интересует поле STAGE_ID, поскольку, принудительно изменяя именно его (разными способами), мы будем перемещать клиента по этапам воронки. На первом этапе это:

"STAGE_ID": "C1:NEW"

Последовательно перемещаясь по этапам и запрашивая данные способом, описанным выше, получим значения для следующих этапов:

2 этап - "STAGE_ID": "C1:PREPARATION"

3 этап - "STAGE_ID": "C1:UC_CBL8F1"

Этап завершения "выигрыш" - "STAGE_ID": "C1:WON"

Этап завершения "провал" - "STAGE_ID": "C1:LOSE"

Этап завершения "анализ причин провала" - "STAGE_ID": "C1:APOLOGY".

В общем-то всё. Как говорил герой одного советского фильма, народ к разврату готов.

Приступим

Итак, для перемещения по этапам нам понадобится метод crm.deal.update, который мы упоминали в предыдущей статье.

Для перемещения на следующий этап сформируем в Postman и отправим вот такой запрос:

https://crmteh.bitrix24.ru/rest/1/________/crm.deal.update.json?id=185&fields[STAGE_ID]=C1:PREPARATION (переходить по этой ссылке бессмысленно, в таком виде она нерабочая, так как api-ключ заменён на строку "____________")

Получили вот такую красоту:

Ну и для закрепления эффекта переведём подобным образом на третий этап

https://crmteh.bitrix24.ru/rest/1/________/crm.deal.update.json?id=185&fields[STAGE_ID]=C1:UC_CBL8F1

Как и ожидалось, сделка переместилась на третий этап

Заключение

Итак, мы изучили некоторые базовые принципы, которые в сущности должны помочь понять логику работы с Битрикс24 из любого внешнего сервиса. Продолжим эту работу в следующих постах - не переключайтесь. Лучше подписывайтесь на обновления этого блога ;).

Благодарность в виде доната приветствуется 😉. Как говорят восточные зулусы, buy me a coffee 😃

👇