Custom 1C and 1C-Bitrix Exchange Development

Standard CommerceML solves 80% of typical tasks: products, prices, stocks, orders. But when a company has 50,000 items with series, characteristics, and multiple prices, standard exchange becomes a problem. Data transfers take days, and at the slightest error, duplicates and gaps occur. Custom exchange eliminates these complexities through precise mapping and parallel processing. We develop turnkey integrations: from audit to production support. Let's break down when custom exchange is needed, which architectures work, and how to avoid common mistakes.

Unlike CommerceML, a custom REST API transfers only changed records — this is 5 times faster on first run. Event-driven exchange via webhook provides real-time relevance, not once an hour. Such architecture is better suited for high-traffic stores.

When is custom exchange necessary?

Standard exchange breaks in these situations:

• Non-standard 1C configuration without CommerceML support (industry-specific solutions, custom configurations)
• Transfer of data not present in CommerceML: requests, tenders, service tickets
• Real-time requirements: stock updates immediately upon change in 1C
• Complex data transformation: data from multiple 1C directories combined into one Bitrix object
• Integration of multiple systems: 1C + CRM + Bitrix through a single gateway

Example from practice: a manufacturing company transferred not only products to Bitrix but also specifications for components related to each order. CommerceML cannot transfer multi-level nesting; we had to design a JSON contract with nested arrays.

Architectural options for custom exchange

Option 1: 1C HTTP services (REST API)

Modern configurations (UT 11.4+, ERP 2.5+, KA 2.5+) support publishing HTTP services. 1C is published on a web server (Apache/nginx), and Bitrix accesses the endpoints via REST.

class OneCApiClient { private string $baseUrl; private string $token; public function getProducts(array $filters = [], int $limit = 100, int $offset = 0): array { return $this->request('GET', '/hs/exchange/products', [ 'modified_since' => $filters['modified_since'] ?? null, 'limit' => $limit, 'offset' => $offset, ]); } public function createOrder(array $orderData): array { return $this->request('POST', '/hs/exchange/orders', $orderData); } public function updateOrderStatus(string $orderId, string $status): bool { $result = $this->request('PUT', "/hs/exchange/orders/{$orderId}/status", [ 'status' => $status, ]); return $result['success'] ?? false; } private function request(string $method, string $path, array $data = []): array { $ch = curl_init(); $url = $this->baseUrl . $path; if ($method === 'GET' && $data) { $url .= '?' . http_build_query($data); } curl_setopt_array($ch, [ CURLOPT_URL => $url, CURLOPT_RETURNTRANSFER => true, CURLOPT_HTTPHEADER => [ 'Authorization: Bearer ' . $this->token, 'Content-Type: application/json', ], CURLOPT_CUSTOMREQUEST => $method, ]); if ($method !== 'GET') { curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data)); } $response = curl_exec($ch); $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); if ($httpCode !== 200 && $httpCode !== 201) { throw new \RuntimeException("1C API error: HTTP {$httpCode}. Response: {$response}"); } return json_decode($response, true); } } 

Option 2: Event-driven exchange (webhooks from 1C)

1C sends an HTTP request to Bitrix when data changes. To do this, a subscription to events (stock change, order status change) and an HTTP request on trigger are added in the 1C configuration.

On the Bitrix side — an endpoint for receiving events:

// /local/api/1c/webhook.php $payload = json_decode(file_get_contents('php://input'), true); $eventType = $payload['event_type'] ?? ''; switch ($eventType) { case 'stock_changed': StockSyncHandler::handle($payload['products']); break; case 'order_status_changed': OrderStatusHandler::handle($payload['order_id'], $payload['status']); break; case 'price_changed': PriceSyncHandler::handle($payload['prices']); break; } http_response_code(200); echo json_encode(['ok' => true]); 

Event-driven exchange provides real-time data relevance — no scheduled polling. This is especially important for high-traffic online stores.

Data transformation

Custom exchange requires explicit mapping logic. A typical complex case: in 1C, a product is stored in three linked directories (Nomenclature, Characteristics, Series), but in Bitrix it should be one infoblock element with trade offers.

class ProductTransformer { public function transform(array $oneCNomenclature): array { $product = [ 'NAME' => $oneCNomenclature['name'], 'CODE' => \CUtil::translit($oneCNomenclature['name'], 'ru'), 'XML_ID' => $oneCNomenclature['guid'], 'ACTIVE' => $oneCNomenclature['active'] ? 'Y' : 'N', 'DETAIL_TEXT' => $oneCNomenclature['description'], 'PROPERTY_ARTICLE' => $oneCNomenclature['article'], 'PROPERTY_BRAND' => $this->getBrandId($oneCNomenclature['manufacturer_guid']), ]; // Собираем торговые предложения из характеристик $offers = []; foreach ($oneCNomenclature['characteristics'] as $char) { $offers[] = [ 'XML_ID' => $char['guid'], 'NAME' => $oneCNomenclature['name'] . ' / ' . $char['value'], 'PROPERTY_COLOR' => $this->getColorId($char['color_guid']), 'PROPERTY_SIZE' => $char['size'], 'CATALOG_PRICE_1' => $char['price'], 'CATALOG_QUANTITY' => $char['stock'], ]; } $product['OFFERS'] = $offers; return $product; } } 

Queues for reliable delivery

Direct synchronous exchange breaks when one of the systems is unavailable. A reliable scheme uses a queue:

// При изменении заказа в Битрикс — добавить задачу в очередь \Bitrix\Main\EventManager::getInstance()->addEventHandler( 'sale', 'OnSaleOrderSaved', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); if ($order->isNew() || $order->getFields()->isChanged('STATUS_ID')) { // Добавить в очередь на передачу в 1С \MyProject\Queue\ExchangeQueue::push([ 'type' => 'order_sync', 'order_id' => $order->getId(), 'created_at' => time(), ]); } } ); 

A worker processes the queue and retries when 1C is temporarily unavailable. We use this approach in all projects — it guarantees delivery even during network failures.

How to ensure exchange stability?

• API versioning: /hs/exchange/v2/products — 1C updates do not break working integrations.
• Monitoring: alerts when the queue falls behind or processing time exceeds limits.
• Document the contract: each endpoint, data format, error codes.
• Regular testing on a staging environment before updating the 1C configuration.

What is included in the work

• Audit of the current exchange scheme (identify bottlenecks, errors, duplication)
• Architecture design: protocol selection (REST, webhook, queue), contract agreement
• Development: writing API client, event handlers, transformers
• Documentation: endpoint descriptions, formats, deployment instructions
• Testing on a test environment: test coverage for all scenarios
• Launch and monitoring for two weeks after start
• Training responsible personnel: how to add new objects, log errors, restart processing

Development timelines

Contact us for an assessment of your project — we will select the optimal architecture and provide timelines within a day. With over 10 years of experience and dozens of successful integrations, we provide realistic estimates without surprises. Order a free audit of your current exchange.