Битрикс24.Маркет: как разместить свою интеграцию

Битрикс24.Маркет — витрина готовых приложений внутри самого портала, откуда администратор компании ставит интеграцию в один клик, без поиска на сторонних сайтах. Разместить там своё приложение — рабочий канал дистрибуции, но путь от кода до опубликованной карточки в Маркете включает регистрацию партнёрского аккаунта, оформление манифеста приложения, прохождение модерации и последующие обязательства по поддержке. Разберём весь путь и типичные причины отказа на модерации.

Партнёрский кабинет и типы приложений

Публикация в Маркете начинается с регистрации в партнёрском кабинете разработчиков Битрикс24 (отдельно от обычной учётной записи портала). После регистрации доступно создание приложения одного из типов: обычное REST-приложение с виджетами и роботами, чисто визуальное приложение (например, только виджет без сложной бизнес-логики), или коробочное решение для локальной версии Битрикс24 — каждый тип имеет собственные требования к манифесту и собственный процесс проверки.

Манифест приложения

Манифест — это структурированное описание приложения: название, категория в каталоге Маркета, список запрашиваемых scope, ссылки на Handler для установки/удаления, описание тарифных планов (если приложение платное), контакты поддержки, а также обязательные текстовые материалы — краткое и полное описание на русском (и желательно на английском для международных порталов), скриншоты интерфейса, значок приложения по заданным требованиям к размеру и формату.

// Пример фрагмента манифеста (упрощённо, по смыслу полей формы в кабинете)
{
  "name": "Проверка контрагента по ИНН",
  "category": "CRM",
  "scope": ["crm", "placement"],
  "install_handler": "https://yourservice.example.com/b24/install",
  "uninstall_handler": "https://yourservice.example.com/b24/uninstall",
  "pricing": { "type": "subscription", "trial_days": 14 }
}

Требования модерации: что чаще всего отклоняют

Модерация Битрикс24 проверяет не только техническую работоспособность, но и соответствие заявленной функциональности реально запрошенным правам, наличие внятной политики обработки персональных данных на сайте разработчика, работоспособность обработчика удаления (проверяют установку и деинсталляцию вручную), и корректность отображения приложения на разных языковых версиях портала, если заявлена мультиязычность. Частые причины отказа — избыточные scope без объяснения в описании, нерабочий Handler на момент проверки, отсутствующая или формальная страница поддержки.

• Запрошенные scope не соответствуют описанной функциональности приложения
• Обработчик деинсталляции не реализован или работает некорректно (проверяется вручную модератором)
• Отсутствует политика обработки персональных данных на сайте разработчика
• Скриншоты не соответствуют реальному интерфейсу приложения на момент проверки
• Приложение падает или показывает ошибку при первом открытии на тестовом портале модератора

Тарификация: разовая продажа, подписка, freemium

Маркет поддерживает несколько моделей монетизации: разовая покупка, периодическая подписка (месяц/год) с автоматическим списанием через встроенный биллинг Битрикс24, бесплатное приложение с пробным периодом на платные функции, и полностью бесплатное приложение (например, как часть более широкой продуктовой линейки, монетизируемой отдельно). Встроенный биллинг Маркета берёт на себя выставление счетов и продление подписки, но и удерживает комиссию с оборота — при проектировании цены закладывайте эту комиссию в расчёт, а не только себестоимость разработки и поддержки.

Тестовая установка перед публикацией

Прежде чем отправлять приложение на модерацию, обязательно пройдите полный цикл на тестовом портале от лица обычного администратора, а не разработчика: установка через тот же интерфейс, каким её увидит реальный клиент, проверка всех виджетов и роботов на реальных данных, затем полная деинсталляция с проверкой, что не остаётся сиротских записей в интерфейсе (зависшие вкладки, недоступные пункты меню). Модератор пройдёт этот же путь при проверке — лучше найти проблемы до подачи заявки, чем получить отказ с формальной причиной и терять цикл повторной проверки, который может занимать несколько рабочих дней.

1. 1.Зарегистрировать приложение в партнёрском кабинете и заполнить манифест полностью
2. 2.Пройти полный цикл установка → использование → деинсталляция на тестовом портале
3. 3.Подготовить материалы: описание, скриншоты, значок, страницу поддержки с политикой данных
4. 4.Отправить на модерацию и оперативно отвечать на вопросы модератора при необходимости правок
5. 5.После публикации — следить за отзывами и рейтингом карточки, они напрямую влияют на видимость в каталоге

Правило соответствия описания и прав. Каждый запрошенный scope должен быть явно объясним через функциональность, описанную в карточке приложения. Если сложно объяснить пользователю, зачем «Проверке контрагента» доступ к телефонии — это повод убрать лишний scope, а не переписать описание под уже выбранные права.

Поддержка после публикации: обязательства перед клиентами

Публикация в Маркете — это не разовое событие, а начало обязательств: клиенты будут писать в поддержку через встроенную форму обратной связи Маркета, ожидать реакции на баг-репорты и обновления при выходе новых версий ядра Битрикс24, которые иногда меняют поведение отдельных методов REST API. Приложение с плохими отзывами о поддержке теряет позиции в каталоге даже при хорошей технической реализации — заложите ресурсы на поддержку сразу, а не только на разработку до момента публикации.

Модерация в Маркете проверяет не только код — она проверяет, готовы ли вы отвечать за это приложение перед чужими клиентами следующие несколько лет.

Курс школы: Вебхуки в Битрикс24 без программирования — от 9 990 ₽

Версионирование и обновления опубликованного приложения

Обновление уже опубликованного приложения не требует повторной установки клиентами — код на вашем сервере меняется, и все установки сразу начинают работать по новой логике, если только вы не меняете состав запрашиваемых scope. Расширение прав доступа (новый scope) требует повторного одобрения каждым клиентом при следующем открытии приложения — учитывайте это при планировании крупных фич, требующих новых прав: часть клиентов может отложить подтверждение, и на переходный период приложение должно корректно работать в состоянии «старые права, новая версия кода», не падая с ошибкой доступа при попытке использовать ещё не подтверждённую клиентом функциональность.

Аналитика использования и удержание клиентов

После публикации важно отслеживать не только продажи, но и фактическое использование: сколько установок остаются активными через месяц, какие функции вызываются чаще, на каком шаге воронки установки клиенты чаще всего сталкиваются с ошибкой. Такая аналитика собирается на вашей стороне (логи вызовов от разных member_id), а не предоставляется Маркетом в готовом виде — без неё сложно понять, почему конверсия из установки в оплаченную подписку низкая, если триальный период истекает без активного использования приложения клиентом.

Локализация карточки приложения для разных рынков

Маркет Битрикс24 работает не только в России — портал доступен в СНГ, странах Балтии, ряде других регионов с локальными версиями интерфейса. Если приложение ориентировано на международную аудиторию, карточка в Маркете и сам интерфейс приложения должны поддерживать как минимум английский язык дополнительно к русскому — иначе на модерации для международной публикации последует замечание, а после публикации — низкая конверсия установок среди пользователей нерусскоязычных порталов, которые просто не поймут интерфейс на незнакомом языке.

Взаимодействие с несколькими тарифными планами внутри одного приложения

Если продукт предполагает несколько тарифов (базовый, расширенный, корпоративный) с разным набором функций, разграничение доступа к функциональности реализуется не на уровне Маркета — сам Маркет только фиксирует факт покупки конкретного тарифа и передаёт эту информацию через биллинговое REST API (bizproc.subscription или аналогичные методы биллинга, зависящие от актуальной версии платформы). Логика ограничения функций по тарифу целиком лежит на вашей стороне: сервер должен на каждый запрос проверять активный тариф установки по member_id и соответствующим образом включать или выключать функциональность, а не полагаться на то, что Маркет сам скроет часть интерфейса.

Работа с отзывами и рейтингом

Карточка приложения в Маркете накапливает отзывы и рейтинг от установивших его компаний — это единственный публичный сигнал качества для новых потенциальных клиентов, просматривающих каталог. Негативный отзыв, оставленный без ответа, читается новыми посетителями карточки как подтверждённая проблема без реакции разработчика; развёрнутый и вежливый ответ с описанием предпринятых мер (даже если сама проблема уже решена в новой версии) существенно снижает репутационный эффект единичного негативного отзыва и показывает потенциальным клиентам, что за приложением есть живая команда поддержки.

Повторная модерация при значимых изменениях

Не каждое обновление кода требует повторного прохождения модерации, но значимые изменения — расширение списка scope, смена модели тарификации, добавление новой категории функциональности — как правило требуют уведомления площадки и иногда повторной проверки. Планируйте такие изменения заранее, с запасом времени на цикл модерации перед анонсом новой версии клиентам, чтобы не оказаться в ситуации, когда обновление готово, но ждёт одобрения площадки, а клиенты уже проинформированы о дате релиза.

Альтернатива Маркету: прямое распространение локальных приложений

Не каждое приложение обязано идти через Маркет — если целевая аудитория узкая (например, несколько десятков клиентов вашего агентства), проще распространять локальное приложение напрямую: клиент сам регистрирует его в своём портале по вашей инструкции, минуя модерацию и комиссию площадки. Такой путь снижает трение при доставке продукта конкретным клиентам, но лишает вас видимости в каталоге и удобного встроенного биллинга Маркета — выбор зависит от того, важнее ли вам широкий охват через витрину или полный контроль над процессом продажи и поддержки без посредника.

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