Классический запрос от клиента звучит просто: хотим, чтобы заказы из Bitrix24 сами попадали в 1С. На деле за этой фразой прячется десяток технических решений, каждое со своими компромиссами.
Для простых сценариев, скажем, создание сделки в Bitrix24 при поступлении заказа на сайте, входящего вебхука достаточно: Bitrix24 даёт готовый URL, на который можно отправить POST-запрос с нужными полями. Проблема начинается, когда нужна двусторонняя синхронизация: обновление статуса оплаты в 1С должно долетать обратно в Bitrix24, и наоборот. Здесь входящих вебхуков уже мало, нужно полноценное REST-приложение с OAuth 2.0, установленное как локальное приложение внутри портала клиента, с доступом к нужным правам через scope Bitrix24.
Самая частая ошибка в таких интеграциях, синхронная обработка вебхука прямо в моменте запроса без очереди. Если 1С в этот момент недоступна или отвечает медленно, Bitrix24 может повторить доставку вебхука, и на выходе получается задвоенный заказ. Мы всегда ставим между системами очередь, обычно RabbitMQ либо, для менее нагруженных проектов, буферную таблицу в Postgres с воркером на polling, и делаем обработчик идемпотентным по внешнему идентификатору сделки, чтобы повторная доставка события не создавала дубль.
1С и Bitrix24 по-разному смотрят на одни и те же сущности: то, что в 1С является строкой документа реализации, в Bitrix24 превращается в товарную позицию сделки со своим набором пользовательских полей. Отдельный слой маппинга, который переводит одну модель данных в другую и логирует каждое расхождение, экономит недели дебага в проде, когда через пару месяцев выясняется, что скидки считаются по-разному в двух системах.
Мы закрываем такие интеграции полным циклом: от анализа бизнес-процесса и выбора архитектуры обмена до написания middleware-сервиса и его сопровождения. Если у вас уже есть кривая самописная интеграция, которая периодически теряет заказы, обычно дешевле сделать аудит существующей схемы, чем переписывать всё с нуля.