Выгрузка данных из Битрикс24: BI-коннектор, REST API, SQL и Excel

Выгрузить данные из Битрикс24 можно через штатный экспорт Excel/CSV, BI-коннектор, REST API, а в коробочной версии — ещё и напрямую из базы данных или её реплики. Выбор зависит от состава данных, глубины истории, частоты обновления и готовности сопровождать интеграцию. Один способ удобен для разовой сверки, другой — для регулярного отчёта, третий — для собственного хранилища.

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

Проверено по официальной документации 24 сентября 2026 года. Тарифные условия и состав API могут меняться.

Как выбрать способ выгрузки данных из Битрикс24

Начните с вопроса к данным. Для списка открытых сделок на сегодня достаточно текущего состояния карточек. Для конверсии по стадиям нужна история переходов. Для выручки и дебиторской задолженности потребуются оплаты и финансовые документы: сумма сделки сама по себе не доказывает получение денег.

Это сравнение архитектур, а не рейтинг по скорости. Измерять нужно полный цикл: получение → запись → преобразование → обновление BI-модели. Быстрый SQL-запрос не поможет, если отчёт читает вчерашнюю импортированную модель.

В облаке нет штатного SQL-доступа к внутренней базе портала. Подключение внешней PostgreSQL или MySQL к BI-инструменту означает работу с отдельным источником либо уже выгруженной копией. Это не доступ к серверной БД облачного Битрикс24.

1. Штатные выгрузки XLS / Excel и CSV

В CRM откройте нужную сущность в режиме «Список», задайте фильтр и состав колонок, затем выберите экспорт в Excel или CSV. Доступны дополнительные параметры: все поля, связанные контакты и компании, реквизиты, детализация по товарам. Права на экспорт задаются по сущностям; для контактов также важны тариф и признак «Участвует в экспорте контактов». Подробности — в официальной инструкции по экспорту CRM.

Фразой «выгрузка в XLS» часто называют любой экспорт в Excel. Проверяйте фактический формат скачанного файла и способ его чтения. Расширение, кодировка, разделитель, десятичная запятая и преобразование дат должны входить в настройки импорта, а не определяться каждый раз автоматически.

Что проверить в файле

• Гранулярность. При детализации по товарам сделка занимает несколько строк. Суммирование повторяющейся суммы сделки завысит результат.
• Идентификаторы. Сохраняйте ID и источник файла. Название сделки и имя клиента не подходят для надёжного обновления записей.
• Типы. Телефоны, внешние коды и значения с ведущими нулями загружайте как текст. Суммы преобразуйте с явно заданной локалью.
• Воспроизводимость. Вместе с файлом фиксируйте время экспорта, фильтр, набор полей и ответственного. Иначе два файла «за сентябрь» могут описывать разные выборки.

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

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

2. Штатный BI-коннектор Битрикс24

Встроенный BI-коннектор предоставляет подготовленные аналитические наборы. Например, crm_deal описывает сделки, crm_deal_uf — пользовательские поля, crm_deal_stage_history — историю стадий, crm_deal_product_row — товарные строки. Состав полей опубликован в справочнике наборов сделок.

Это отдельный слой представления данных. Имя crm_deal в аналитическом источнике не означает, что внешнему пользователю открыли физическую таблицу БД. BI Конструктор — среда создания отчётов внутри Битрикс24; BI-коннектор — механизм получения данных. При проектировании интеграции нужно уточнять, о каком из этих компонентов идёт речь.

Тарифные ограничения и актуальная логика лимитов

На дату проверки официальная инструкция подключения Power BI указывает следующие пределы строк: Базовый и Стандартный — 10 000, Профессиональный — 100 000, Энтерпрайз 250/500/1000 — 250 000 / 500 000 / 1 000 000 соответственно. Эти значения нельзя трактовать как гарантированную пропускную способность или переносить на любой способ выгрузки.

В обновлении от 26 августа 2026 года описана новая логика: при превышении лимита блокируется соответствующий запрос; для Power BI требуется обновить код загрузки из актуального шаблона. Поэтому старое утверждение о неизбежной длительной блокировке всей BI-выгрузки уже непригодно как универсальное правило. Проверьте версию загрузчика и ответ источника. Изменения фильтров и лимитов BI.

Практические ограничения

Сначала составьте перечень нужных сущностей и полей и сопоставьте его с реально доступными наборами. Наличие CRM в источнике не означает наличие всех данных портала, файлов и полной истории редактирования. В коробке дополнительно проверяются версия и настройки модуля BI-коннектора.

Проверьте, по какой дате отбирается период. Если запрос ограничен датой создания, изменение старой сделки не обязательно попадёт в новый временной интервал. Фильтр на диаграмме также не гарантирует уменьшения объёма данных, который загрузчик запросил у источника. Для этого ограничение должно действовать на этапе получения данных.

Метод подходит, когда нужные наборы уже существуют и их достаточно для отчёта. Для недостающих объектов возможна комбинированная схема: BI-наборы для основной массы данных, REST для дополнений. Заранее определите общий ключ и источник истины для каждого поля, чтобы два канала не перезаписывали друг друга случайным образом.

3. Выгрузка через REST API Битрикс24

REST API возвращает бизнес-объекты через документированные методы. Можно выбирать поля и фильтры, читать справочники и строить собственную загрузку. Авторизация через вебхук или приложение определяет доступ; доступность REST и условия его использования нужно проверить для конкретного портала. Полный список таблиц внутренней БД через REST не предоставляется.

Начните с метаданных

Для универсальных CRM-методов сначала получите описание полей через crm.item.fields. Для сделки entityTypeId равен 2; идентификаторы своих смарт-процессов нужно получить из конфигурации портала. Сохраните тип поля, множественность, код и варианты списка. Пользовательское название может измениться, поэтому связывать интеграцию только по подписи поля ненадёжно.

Не смешивайте форматы методов. Например, специализированный crm.deal.list использует поля вида DATE_MODIFY, а универсальный crm.item.list — updatedTime. У второго элементы находятся в result.items. Параметры и структуру ответа проверяют по документации конкретного метода.

Пример чтения изменённых сделок

Ниже тело запроса к crm.item.list. Интервал учебный, часовой пояс указан явно. Секрет авторизации хранится отдельно и не включается в код отчёта, доступный зрителям.

{
  "entityTypeId": 2,
  "select": ["id", "title", "updatedTime", "stageId", "opportunity", "currencyId"],
  "filter": {
    ">=updatedTime": "2026-09-23T00:00:00+03:00",
    "<updatedTime": "2026-09-24T00:00:00+03:00"
  },
  "order": {"id": "ASC"},
  "start": 0
}

Прочитайте result.items, затем передавайте значение next в start следующего запроса с теми же условиями. Завершайте проход после отсутствия следующей страницы. Нельзя считать первый успешный ответ полной выгрузкой. Для больших объёмов документация также описывает выборку по возрастающему ID с start = -1, отключающим подсчёт общего количества; такой алгоритм внедряют отдельно, с учётом поддерживаемых параметров метода. Рекомендации по большим выборкам.

Лимиты REST и обработка ошибок

В облаке действует ограничение длительности запроса в 60 секунд и механизм регулирования частоты: для большинства тарифов счётчик уменьшается на 2 запроса в секунду, для Энтерпрайз — на 5. Есть отдельное ограничение ресурсоёмкости методов. Ошибки QUERY_LIMIT_EXCEEDED и OPERATION_TIME_LIMIT требуют разных правил повторной попытки; для второй учитывают operating_reset_at. Значение 480 секунд в текущей документации приведено как пример, а не универсальная константа. Актуальные лимиты REST API.

batch объединяет до 50 вызовов. Это экономит HTTP-запросы, но вложенные методы продолжают расходовать свой лимит ресурсоёмкости. Проверяйте ошибки каждого подзапроса: успешный HTTP-ответ пакета не доказывает успех всех его частей.

Практически это означает очередь запросов, ограниченную параллельность, повтор с увеличивающейся задержкой и журнал ошибок. Не пытайтесь «ускорить» нестабильную загрузку десятками потоков. Сначала уберите ненужные поля и лишние обращения за одной и той же сущностью.

Надёжный инкремент: не только фильтр по дате

1. Сохраните верхнюю границу прохода T до начала чтения. Нижнюю возьмите из последней успешно завершённой загрузки с небольшим перекрытием.
2. Загрузите все страницы окна во временный слой. Сохраняйте ключ портала, тип сущности, ID, дату изменения источника и время получения.
3. Выполните идемпотентное обновление: повторное получение той же версии записи не создаёт дубль и не затирает более новую версию.
4. Сдвигайте контрольную отметку на T только после успешной записи всего окна. При сбое возобновите проход или безопасно перечитайте окно.
5. Периодически сверяйте состав ID и перечитывайте согласованные исторические периоды. Многостраничный REST-запрос не является единой транзакционной фотографией работающей CRM.

Удаления требуют отдельного механизма. Удалённая карточка не вернётся в обычной выборке «изменено после даты». Используйте доступные события удаления совместно с регулярной сверкой ID. Сначала убедитесь, что обход завершён и права не изменились; только затем помечайте отсутствующие объекты. Ошибка авторизации или пустая страница не должны превращаться в массовое удаление витрины.

Изменение товара, связи или справочника не стоит автоматически считать изменением основной сделки. У дочерних сущностей должен быть собственный способ обновления. События помогают сократить задержку, но требуют очереди, повторной обработки и контроля пропусков; они не восстанавливают историю, которую интеграция раньше не получала.

4. Прямое подключение к базе данных коробочного Битрикс24

В коробке администратор может предоставить чтение физической БД. Это позволяет использовать SQL, соединять таблицы на сервере и получать данные, для которых нет подходящего внешнего метода. Но такой доступ создаёт зависимость от версии продукта, установленных модулей и доработок.

Рабочая база CRM рассчитана прежде всего на пользовательские операции. Тяжёлый отчёт может конкурировать за процессор, память, дисковый ввод-вывод и кэш. Даже запрос только на чтение не означает отсутствие влияния на production. Большие выборки оценивают по плану выполнения, времени и нагрузке; для регулярного BI предпочтительнее выделенный контур.

• Используйте отдельного пользователя с минимальными правами чтения, ограничением сетевого доступа и защищённым соединением.
• Предоставляйте аналитикам ограниченные представления или витрины вместо всех таблиц. Прямой SQL не применяет автоматически права CRM.
• Фиксируйте версию модулей, DDL нужных таблиц и ожидаемые типы колонок. После обновления коробки повторяйте проверки.
• Не добавляйте индексы и не меняйте системные таблицы по рекомендации из статьи без проверки на стенде и отдельного решения администратора.

У коробки есть и промежуточный вариант: собственный серверный обработчик на PHP с использованием API модулей или D7 ORM. Он помогает сосредоточить знание внутренней схемы в одном месте, но всё равно требует проверки прав, нагрузки, авторизации и совместимости после обновлений.

5. Репликация базы и CDC: отдельный контур аналитики

Реплика получает изменения рабочей БД, а аналитические запросы выполняются на отдельном сервере. Это переносит основную нагрузку чтения с CRM, но не делает инфраструктуру бесплатной: источник обслуживает поток репликации, а реплика должна успевать применять изменения и выполнять запросы.

В асинхронной репликации MySQL копия может отставать. Для восстановления после разрыва необходимы ещё доступные журналы изменений. Контролируйте не только доступность сервера, но и применение событий, ошибки и задержку относительно источника. Официальные пояснения MySQL о репликации.

Реплика, CDC и хранилище решают разные задачи

Для CDC проектируют согласованный начальный снимок, позицию журнала, возобновление после сбоя, дедупликацию событий и реакцию на изменение схемы. Если старые журналы уже удалены, одного сохранённого offset недостаточно: может понадобиться новый снимок. Перенос из MySQL в PostgreSQL или другую СУБД — отдельный процесс преобразования и доставки, а не обычная однотипная репликация.

Реплика не заменяет резервную копию: ошибочное удаление обычно попадёт и в неё. Историю для анализа хранят отдельно, а резервное копирование проверяют восстановлением. MySQL описывает использование реплики как источника для создания бэкапа, а не как замену самому бэкапу. Репликация и резервное копирование.

При частичной репликации учитывайте зависимости таблиц: карточки без пользовательских полей и справочников могут быть технически доступны, но аналитически неполны. Файлы и вложения также не следует считать перенесёнными только потому, что скопированы записи БД с их идентификаторами.

Структура базы данных Битрикс24: три разных уровня

Фраза «таблица сделок Битрикс24» неоднозначна. Разделяйте бизнес-объект в REST, аналитический набор и физическую таблицу коробки. Для базовой ориентации также пригодится справочник структуры данных и связей CRM.

Карта основных таблиц коробки

Ниже — ориентиры для исследования типичной CRM-схемы, а не стабильный контракт для всех версий. Перед SQL-подключением подтвердите наличие таблиц, колонок и ключей на своей установке. Внутренние таблицы нельзя автоматически выводить из имён BI-наборов.

Множественная связь сделки с контактами и роль основного контакта описаны в документации CRM по клиентам; хранение товарных строк — в документации коллекций CRM. Для смарт-процессов и истории стадий определяйте физическое хранение через установленный модуль и его ORM, не подставляйте ID типа в предполагаемое имя таблицы.

Как проверить схему перед написанием SQL

Пример ниже читает только метаданные MySQL-совместимой БД. Выполняйте его под разрешённой учётной записью на своей коробке или реплике; подключение к нужной базе должно быть выбрано заранее.

SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, IS_NULLABLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME IN (
    'b_crm_deal',
    'b_crm_deal_contacts',
    'b_crm_product_row',
    'b_uts_crm_deal',
    'b_utm_crm_deal'
  )
ORDER BY TABLE_NAME, ORDINAL_POSITION;

Сохраните результат и сведения об индексах. Затем проверьте связи на небольшой известной выборке. Наличие поля с похожим названием ещё не доказывает его бизнес-смысл. Удалённые, архивные и служебные записи могут обрабатываться приложением отдельно, поэтому прямой SQL следует сверять с карточками и поддерживаемым API.

Пользовательские поля и полиморфные связи

В поле-списке может храниться ID варианта, в поле «сотрудник» — ID пользователя, в привязке CRM — ссылка на объект определённого типа. Сохранение только отображаемого текста лишает модель устойчивого ключа. Храните и исходное значение, и отдельную расшифровку.

Для множественного поля предпочтительна отдельная таблица «объект → значение». Если разворачивать его в строки основной таблицы сделок, изменится гранулярность и начнут повторяться суммы. Для дел и других объектов, связанных с несколькими типами CRM, ключ должен включать тип владельца: одинаковый числовой ID сделки и контакта обозначает разные объекты.

Как превратить выгрузку в модель для BI

Полезно разделить сырой слой, очищенные таблицы и витрины. В сыром сохраняют полученные значения и служебные отметки; в очищенном приводят типы и ключи; в витринах закрепляют определения показателей. Такой подход позволяет разбирать расхождения без повторного обращения ко всем данным CRM. Подробнее — о выборе ETL и ELT.

Битрикс24
  → Excel / BI-наборы / REST / реплика
  → сырой слой + журнал загрузок
  → сделки, товары, события, связи, справочники
  → витрины с согласованными показателями
  → Power BI / DataLens / Superset

Одна таблица — одна гранулярность

• fact_deal: одна строка на сделку в текущем состоянии.
• fact_deal_product: одна строка на товарную позицию сделки.
• fact_stage_event: одна строка на событие перехода по стадии.
• bridge_deal_contact: одна строка на связь сделки с контактом.
• Справочники сотрудников, воронок, стадий и календарь: отдельные таблицы с проверенными ключами.

Это пример собственной модели хранилища, а не названия объектов Битрикс24. Для нескольких порталов включайте portal_id в ключи и условия соединения.

Пример: почему JOIN увеличил сумму в шесть раз

У учебной сделки сумма 120 000 ₽, три товарные строки и два события стадии. Если соединить обе дочерние таблицы со сделкой по ID, получится 3 × 2 = 6 строк. Обычный SUM суммы сделки покажет 720 000 ₽. Загрузка может быть полной, а отчёт — неверным.

Решение: считать сумму сделок на уровне сделки, а дочерние данные агрегировать до соединения либо моделировать отдельными фактами. SUM(DISTINCT сумма) не исправляет задачу: две разные сделки с одинаковой суммой тогда схлопнутся.

Пример SQL для собственной витрины. Предполагается уникальность (portal_id, deal_id) в fact_deal. Запрос добавляет число товарных строк, сохраняя одну строку на сделку:

WITH product_counts AS (
  SELECT portal_id, deal_id, COUNT(*) AS product_rows
  FROM fact_deal_product
  GROUP BY portal_id, deal_id
)
SELECT d.portal_id, d.deal_id, d.amount, d.currency_id,
       COALESCE(p.product_rows, 0) AS product_rows
FROM fact_deal AS d
LEFT JOIN product_counts AS p
  ON p.portal_id = d.portal_id
 AND p.deal_id = d.deal_id;

История, деньги и даты

Текущее поле стадии не отвечает на вопрос, сколько раз сделка возвращалась назад. Для времени на этапах нужны события, упорядоченные по времени и устойчивому дополнительному ключу. Конец интервала обычно выводят из следующего перехода; отдельно определяют правила для незавершённой сделки и повторного открытия. Нельзя автоматически считать START_DATE и END_DATE BI-набора длительностью пребывания на конкретной стадии: сверяйте назначение полей в справочнике.

История стадий не равна истории всех полей. Если нужно знать ответственного или сумму «как было на конец прошлого месяца», сохраняйте версии или периодические снимки. Из сегодняшней карточки нельзя достоверно восстановить все прошлые состояния.

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

Как принять готовую выгрузку: контрольный набор

До большого отчёта соберите небольшой набор существующих объектов: сделка с товарами, несколькими контактами, пользовательским списком, пустым полем, переходами назад и старой датой создания. Для удаления используйте только согласованный тестовый контур или уже известный факт удаления. Следующие проверки подходят и для собственного загрузчика, и для готового коннектора.

1. Полнота: число уникальных ID при одинаковых правах, фильтрах и моменте сверки. Расхождения объяснены конкретными объектами.
2. Деньги: суммы сверены отдельно по валютам; после JOIN они не выросли; оплаты не подменены суммой сделок.
3. Повтор: повторная обработка окна не создаёт дублей, пропусков и отката новых значений.
4. Изменения: обновление старой карточки и её дочерних данных доходит до витрины.
5. Удаления: отличимы от потери прав, смены фильтра и незавершённой выгрузки.
6. Сбой: остановка на середине страницы или пакета не продвигает контрольную отметку раньше записи данных.
7. Схема: добавление и переименование пользовательского поля, новый вариант списка не проходят незамеченными.
8. Свежесть: измерена задержка от изменения в CRM до экрана отчёта, включая реплику, ETL и обновление модели.
9. Доступ: обычный зритель видит разрешённые строки и колонки; проверены также скачивание и прямые ссылки.
10. Эксплуатация: есть ответственный, журнал загрузок, сигнал о сбое и проверенный способ восстановления.

Полезные служебные поля: source_updated_at, extracted_at, loaded_at, batch_id, is_deleted — последнее только при подтверждённом основании. В журнале храните число прочитанных и записанных строк, дубли, ошибки и последнюю успешную границу. «Процесс завершился без исключения» — слишком слабый критерий качества.

Где здесь готовые коннекторы

Готовый коннектор может взять на себя расписание, получение страниц, запись в БД и сопровождение схемы. При выборе, в том числе для BI Data, проверяйте те же критерии: нужные сущности, обработку изменений и удалений, диагностику ошибок, права и восстановление. Сам факт использования коннектора не отменяет ограничения источника и не определяет бизнес-смысл показателей.

Частые вопросы о выгрузке из Битрикс24

Можно ли подключиться к базе облачного Битрикс24 через SQL?

Штатного прямого доступа к внутренней БД облака нет. Используют поддерживаемые API, BI-наборы и экспорт. SQL обычно выполняют уже над собственным хранилищем или аналитическим источником.

Можно ли выгрузить все данные одним методом?

Нельзя рассчитывать на один универсальный метод, который отдаст весь портал с файлами, правами и полной историей. Сначала составляют перечень сущностей и проверяют доступный канал для каждой. Аналитическая выгрузка не является полной резервной копией Битрикс24.

Почему в Excel больше строк, чем сделок?

Например, включена детализация по товарным позициям. Сравнивайте число уникальных ID сделок, а суммы считайте на согласованном уровне детализации.

Достаточно ли обновлять только новые сделки?

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

Что выбрать для большого коробочного портала?

Если регулярные выборки заметно нагружают CRM, рассмотрите реплику и отдельные витрины. Решение принимают после измерения нагрузки и допустимой задержки, с учётом ресурсов на администрирование. Для отдельных объектов REST может оставаться удобным дополнением.

С чего начать интегратору?

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