Custom Middleware for 1C and Bitrix Integration

A direct connection between 1C and Bitrix is simple as long as there are only two systems. Add warehouses, CRM, and marketplaces — each new connection doubles the complexity. On one project, a client connected three Bitrix sites to a single 1C directly. Every week the synchronization broke, orders w

Our competencies:

Frequently Asked Questions

A direct connection between 1C and Bitrix is simple as long as there are only two systems. Add warehouses, CRM, and marketplaces — each new connection doubles the complexity. On one project, a client connected three Bitrix sites to a single 1C directly. Every week the synchronization broke, orders were duplicated, and stock levels diverged. The average time to fix it was four hours. We designed an intermediate service (middleware) that became a single gateway for all systems. Result: errors disappeared, synchronization time halved.

We build custom middleware when multiple Bitrix sites are connected to one 1C, when synchronization with CRM or marketplaces is required, when the 1C configuration is non-standard, or when data transformation needs extend beyond CommerceML mapping. Middleware isolates the exchange business logic and makes it testable independently. Request an audit — our engineers will assess your project.

Challenges That Middleware Solves

  • Several Bitrix sites connected to a single 1C
  • 1C + Bitrix + CRM (AmoCRM, Bitrix24) — data must sync between all
  • Non-standard 1C configuration without HTTP services — an adapter is needed
  • Data transformation requirements more complex than what CommerceML mapping can handle
  • Exchange business logic must be isolated and testable separately from 1C and Bitrix

Why Middleware Outperforms Direct Integrations

Direct connections turn the architecture into a spider web. Each new system requires changes to all existing links. Middleware reduces synchronization errors by three times thanks to a unified task queue and centralized journal. When a failure occurs, you only need to restart one component instead of patching each link. Our engineers, with over ten years of experience in Bitrix and 1C, guarantee stability even under peak loads. Over the years, we have completed more than 50 integration projects.

Error Handling in Middleware

The task queue uses a backoff mechanism: if a task fails, it automatically retries after 5 minutes. Maximum 3 attempts, after which the error is recorded in SyncLog. Other tasks are not blocked — each item syncs independently. This localizes problems without data loss.

How the Task Queue Works

The queue is built on Redis and Horizon (Laravel) or an equivalent solution. Each task is a class implementing the ShouldQueue interface. On failure, the task retries with exponential backoff. This ensures that temporary failures (e.g., API unavailability) do not lead to data loss.

Architecture and Technical Stack

[1C] ←→ [Middleware] ←→ [Bitrix] ←→ [CRM] ←→ [Marketplace] 

Middleware is a separate application (PHP, Node.js, Python, Go — based on the team's stack). Its core:

  1. Connection adapters: reads/writes to each system via its API
  2. Data mapping: transforms objects from one system's format to another
  3. Task queue: stores sync tasks and ensures retries on failure
  4. Exchange log: history of all operations with results
  5. Configuration rules: which fields to sync, direction, transformations

Adapters and Mappers

Example adapter for Bitrix via REST API:

class BitrixAdapter { private string $webhookUrl; public function getOrders(array $filter = []): array { $response = $this->call('crm.deal.list', [ 'filter' => $filter, 'select' => ['ID', 'TITLE', 'STAGE_ID', 'OPPORTUNITY', 'UF_ORDER_ID'], ]); return $response['result'] ?? []; } public function updateProductStock(int $productId, int $quantity): bool { $response = $this->call('catalog.storeProduct.update', [ 'id' => $productId, 'fields' => ['AMOUNT' => $quantity], ]); return $response['result'] ?? false; } public function createOrder(array $fields): int { $response = $this->call('sale.order.add', ['fields' => $fields]); return $response['result']['order']['id'] ?? 0; } private function call(string $method, array $params = []): array { $response = file_get_contents( $this->webhookUrl . $method . '.json?' . http_build_query($params) ); return json_decode($response, true); } } 

The full method list is described in the Bitrix24 REST API. Mapper with transformation rules:

class ProductMapper { private array $categoryMapping; private array $propertyMapping; public function oneCToBitrix(array $oneCProduct): array { return [ 'IBLOCK_ID' => config('bitrix.catalog_iblock_id'), 'XML_ID' => $oneCProduct['Ref_Key'], 'NAME' => $oneCProduct['Description'], 'ACTIVE' => $oneCProduct['DeletionMark'] ? 'N' : 'Y', 'DETAIL_TEXT' => $oneCProduct['КомментарийДляСайта'], 'IBLOCK_SECTION_ID' => $this->mapCategory($oneCProduct['ОсновнаяТоварнаяГруппа_Key']), 'PROPERTY_ARTICLE' => $oneCProduct['Артикул'], 'PROPERTY_WEIGHT' => $oneCProduct['Вес'] * 1000, 'PROPERTY_BRAND' => $this->resolveBrand($oneCProduct['Производитель_Key']), ]; } } 

Queue and Reliability

class SyncProductsJob implements ShouldQueue { use Dispatchable, InteractsWithQueue, Queueable, SerializesModels; public int $tries = 3; public int $backoff = 300; public function handle(OneCAdapter $oneC, BitrixAdapter $bitrix, ProductMapper $mapper): void { $products = $oneC->getModifiedProducts($this->sinceDate); foreach ($products as $oneCProduct) { try { $bitrixFields = $mapper->oneCToBitrix($oneCProduct); $bitrix->upsertProduct($bitrixFields); SyncLog::create([...]); } catch (\Exception $e) { SyncLog::create([...]); } } } } 

Monitoring

A middleware without a management interface is a black box. Minimal dashboard:

  • Status of recent exchange sessions (success / error / time)
  • List of errors with retry capability
  • Statistics: number of synced objects per day/week
  • Manual sync trigger for individual objects or data types

Implemented as a simple Laravel/Symfony web interface or via Laravel Horizon.

What Is Included in the Work

Stage Output
Systems audit Analysis of current exchanges, versions, volumes. Architecture diagram.
Design Middleware scheme, stack selection, adapter and mapper specification.
Implementation Code for adapters, mappers, queues, logging, dashboard.
Testing Load testing, edge case checks, adjustments.
Documentation Operation manual, API description, deployment scheme.
Training Session for administrators, access handover.
Warranty support 2 months after delivery — bug fixes, consultations.

Development Process

Stage Description
Systems audit Analyze 1C and Bitrix versions, current exchanges, data volume. Identify bottlenecks.
Architecture design Develop middleware scheme, determine stack, adapters, mapping.
Adapter and mapper implementation Write connection code for each system and transformation rules.
Queue and logging setup Implement task queue (Redis + Horizon) and SyncLog journal.
Dashboard development Create interface for monitoring and manual exchange management.
Testing and debugging Conduct load testing, catch edge cases.
Documentation and training Deliver architecture docs and administrator instructions.

Development Timeline

Middleware scope Timeline
Two adapters (1C + Bitrix) + 2–3 mappers + queue 3–5 weeks
+ 3rd system (CRM) + extended mapping +2–3 weeks
+ Dashboard monitoring + manual control +1–2 weeks
Full system for 5+ systems 3–6 months

Contact us for a consultation. Request an audit — our engineers will assess your project and propose the optimal solution.