Смена этапа сделки в Битрикс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 приводит такой набор данных в удобный для понимания вид.
Подготовка
В предыдущем шаге мы подготовили несколько входящих веб-хуков. В частности, просмотр сделки, редактирование сделки.
Попробуем с помощью входящего веб-хука просмотреть поля сделки
Возьмём тестовую воронку, состоящую из трёх этапов
В сервисе 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, поскольку, принудительно изменяя именно его (разными способами), мы будем перемещать клиента по этапам воронки. На первом этапе это:
Последовательно перемещаясь по этапам и запрашивая данные способом, описанным выше, получим значения для следующих этапов:
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 😃