При работе с REST-методами в роботах и бизнес-процессах Битрикс24 часто создаётся ложное ощущение, что если метод корректно отрабатывает через вебхук, то он так же будет работать и внутри робота. На практике это далеко не всегда так. Один и тот же запрос может вести себя по-разному в зависимости от контекста выполнения.
В этом кейсе рассматривалась типовая задача — получить элементы смарт-процесса через метод crm.item.list с фильтрацией по пользовательским полям. Метод известный, параметры стандартные, логика понятная. Тем не менее робот стабильно возвращал ошибку, несмотря на то что визуально запрос выглядел корректным.
В чём была реальная проблема
Ключевая сложность оказалась не в логике запроса и не в правах доступа. Ошибка возникала из-за того, что JSON, передаваемый в REST-действии, содержал неочевидные синтаксические неточности. Речь не о сломанных скобках или отсутствующих ключах, а о мелочах — типах данных, кавычках, запятых и даже пробелах.
Внутри робота Битрикс24 параметры REST-действия интерпретируются строже, чем при обычном вызове вебхука. Если JSON формально невалиден или допускает неоднозначное трактование, отдельные параметры могут просто не передаться в метод. При этом ошибка указывает не на синтаксис, а, например, на «отсутствующий» обязательный параметр.
Именно это и произошло: entityTypeId был указан, но из-за формата JSON фактически не доходил до метода.
Почему стандартная логика подводит
Многие ориентируются на примеры из документации или обучающих видео, где JSON может выглядеть упрощённо. Однако в реальных REST-действиях роботов такие упрощения не всегда допустимы. Числовые значения, переданные без кавычек, смешение типов, лишние запятые — всё это способно нарушить выполнение, даже если внешне запрос кажется правильным.
На этом этапе особенно полезным оказался подход, реализуемый в приложении REST API - методы РЕСТ Битрикс24 и JSON в роботах и БП. Оно позволяет работать с REST-запросами максимально явно и контролируемо, не полагаясь на «автоисправления» со стороны системы.
Как была решена задача
Решение оказалось проще, чем ожидалось, но требовало аккуратности. Все значения в JSON были приведены к строковому формату, использованы одинаковые кавычки, убраны лишние запятые и проверена валидность всего тела запроса целиком. После этого тот же самый метод, с той же логикой фильтрации, начал корректно отрабатывать в роботе без каких-либо дополнительных изменений.
Важно, что изменение коснулось исключительно синтаксиса, а не бизнес-логики. Это наглядно показало, насколько чувствительны REST-действия Битрикс24 к формальным деталям.
Результат и практический вывод
В итоге робот стал стабильно выполнять REST-запрос, корректно получать данные и передавать их дальше по сценарию бизнес-процесса. Ошибка исчезла полностью и больше не воспроизводилась.
Главный вывод из этого кейса — при работе с REST в Битрикс24 нельзя относиться к JSON как к «примерному формату». Он должен быть строгим, однозначным и валидным до символа. Именно такой подход закладывался и при разработке REST API - методы РЕСТ Битрикс24 и JSON в роботах и БП, который нативно используется в сложных автоматизациях, где цена ошибки слишком высока.
Если REST-действие в роботе ведёт себя странно, почти всегда стоит начать не с прав и не с метода, а с самых мелких деталей синтаксиса. В Битрикс24 именно они решают, будет ли автоматизация работать или нет.
