Dropshipping on Bitrix: Setup Cases, Timelines, Automation

Imagine: a store takes orders, the supplier ships directly to the customer. The logic is simple, but standard Bitrix has no built-in routing by suppliers, real-time stock synchronization, or payment splitting. Without custom development, each order requires manual processing — a manager checks availability, coordinates with the supplier, enters data. At 200 orders per day, that's 4 hours of routine, errors, and delays. We solve this problem: over 10 years we've set up dropshipping for 50+ projects — from small online stores to federal marketplaces. For example, for an electronics chain we implemented a system with 15 suppliers processing 2000 orders per day. Result: 70% reduction in manual labor and elimination of shipping errors. Our engineers are certified 1C-Bitrix specialists, guaranteeing a transparent implementation process.

Problems Solved by Dropshipping on Bitrix

The main pain is manual order processing. Without automation, a manager spends up to 5 minutes per order: check supplier stock, agree on price, transfer data. At 500 orders per day, that's over 40 hours per week. The second problem is stock discrepancies. Suppliers update data unevenly: some every hour, some once a day. As a result, the store sells items that are not in stock. This leads to order cancellations and loss of trust. The third is payment splitting. If the supplier requires payment after shipment, and you take money immediately, you need a transparent settlement system. We solve all three tasks through custom development: create a unified supplier management system, real-time stock synchronization, and flexible order routing.

How Dropshipping Works on Bitrix

A minimal dropshipping system rests on three elements:

1. Product-to-supplier binding via an infoblock property or HL-block.
2. Order routing — when an order is created, we determine which suppliers to transfer items to.
3. Stock synchronization — the supplier transmits current data via API or file.

Each point requires careful design: without proper architecture, errors in orders and stock discrepancies arise. For example, if you don't configure validation when changing suppliers, you might send an order for a product that has been discontinued.

How to Organize Order Routing by Suppliers

When creating an order, the handler on the OnSaleOrderSaved event splits items by suppliers and sends notifications. This approach is used in 90% of projects.

// /local/php_interface/init.php AddEventHandler('sale', 'OnSaleOrderSaved', ['\\Local\\Dropshipping\\OrderRouter', 'route']); 

// /local/lib/Dropshipping/OrderRouter.php namespace Local\\Dropshipping; use Bitrix\\Main\\Application; class OrderRouter { public static function route(\\Bitrix\\Sale\\Order $order): void { $supplierItems = []; foreach ($order->getBasket() as $item) { $productId = (int)$item->getProductId(); $supplierId = self::getSupplierByProduct($productId); if ($supplierId) { $supplierItems[$supplierId][] = [ 'product_id' => $productId, 'name' => $item->getField('NAME'), 'quantity' => $item->getQuantity(), 'price' => $item->getPrice(), 'sku' => self::getSupplierSku($productId, $supplierId), ]; } } foreach ($supplierItems as $supplierId => $items) { self::notifySupplier($order, $supplierId, $items); } } private static function notifySupplier(\\Bitrix\\Sale\\Order $order, int $supplierId, array $items): void { $supplier = self::getSupplierData($supplierId); if (!empty($supplier['WEBHOOK_URL'])) { self::sendWebhook($supplier['WEBHOOK_URL'], $order, $items); } else { self::sendEmail($supplier['EMAIL'], $order, $items); } } } 

Important: the handler must account for partial shipment and returns. We add statuses 'Awaiting supplier' and 'Transferred to supplier' to avoid duplicate notifications.

Why HL-blocks Are Better Than Infoblock Properties

For binding products to suppliers, we use the SupplierProduct HL-block:

An HL-block is more convenient: supports multiple suppliers per product, stores purchase prices separately from retail, and is easily extensible. Infoblock properties quickly become unmanageable with dozens of suppliers. If you have 50 suppliers and 10,000 products, an HL-block with an index on UF_PRODUCT_ID ensures fast queries, while infoblock properties lead to performance degradation.

How We Solve Stock Synchronization

Stock synchronization is a key failure point. If stock isn't updated in time, the store sells what the supplier doesn't have. We set up two scenarios:

• Pull — scheduled agent. Every 10 minutes, an agent requests stock and updates the quantity in the warehouse. Suitable for 80% of cases.
• Push — webhook from the supplier. The supplier sends a POST request with current stock. Processed in real time, but requires custom work on the supplier's side.

Each supplier gets a separate warehouse in b_catalog_store. Stock is stored in b_catalog_store_product. This allows seeing not just overall stock but the stock of a specific supplier. A typical mistake is confusing warehouses during synchronization. We set up a mapping supplier_id ↔ store_id to ensure data goes to the right place.

// Agent running every 10 minutes function syncSupplierStocks(): string { $suppliers = getSuppliers(); foreach ($suppliers as $supplierId) { $stocks = fetchSupplierStocks($supplierId); updateStocks($supplierId, $stocks); } return __FUNCTION__ . '();'; }