Developing a Dropshipping Schema with Suppliers on 1C-Bitrix

When processing orders manually with 10 suppliers, up to 15% errors occur — lost orders, duplicates, incorrect stock levels. Scaling to 50 suppliers makes the process unmanageable. We have designed over 30 dropshipping schemas on 1C-Bitrix that process up to 5,000 orders per day without manual intervention. The key challenges are real-time stock synchronization and correct routing with multiple suppliers. Off-the-shelf modules cannot handle these tasks. A poorly designed schema breaks when adding a second supplier or when volume exceeds 100 orders per day. Our experience: 7+ years in Bitrix development and 30+ projects. We guarantee correct routing and timely stock syncing. Contact us for a free assessment of your project — we will analyze your current infrastructure and prepare a solution.

Why Standard Modules Are Not Suitable for Dropshipping?

Ready-made modules often offer simple supplier substitution but ignore complex routing, multiple stock sources, and rejection automation. We have to design a custom data model and handlers adaptable to any supplier.

Data Model for Linking Products and Suppliers

The central question: how to link a product to a supplier and store data for order routing.

The product information block (b_iblock_element, b_iblock_element_property) stores retail data: name, description, images, properties. We leave that untouched.

HL-block Supplier — supplier directory: b_uts_supplier (auto-generated table of the HL-block)

• ID
• UF_NAME — supplier name
• UF_EMAIL — email for notifications
• UF_WEBHOOK_URL — URL for POST notifications
• UF_API_KEY — API key for supplier access
• UF_FEED_URL — URL of the stock feed (XML/CSV/JSON)
• UF_FEED_FORMAT — feed format
• UF_LEAD_TIME — order processing time (days)
• UF_ACTIVE — active flag

HL-block SupplierProduct — link between products and suppliers: b_uts_supplier_product

• ID
• UF_PRODUCT_ID — ID of the info-block element (b_iblock_element.ID)
• UF_SUPPLIER_ID — ID of the supplier (b_uts_supplier.ID)
• UF_SUPPLIER_SKU — supplier's SKU
• UF_PURCHASE_PRICE — purchase price
• UF_CURRENCY — purchase currency
• UF_STORE_ID — supplier's warehouse (b_catalog_store.ID)
• UF_MIN_QUANTITY — minimum order quantity
• UF_IS_PRIMARY — primary supplier (if multiple)

Warehouses (b_catalog_store) — one per supplier. Stock in b_catalog_store_product. This is the standard Bitrix mechanism, no need to reinvent the wheel.

How to Design Order Routing?

The router's task: when an order is created, split the cart, group items by supplier, and transmit each part to the respective supplier. The complication: one product may have multiple suppliers. We need selection logic: by price, availability, priority. We implement this via UF_IS_PRIMARY combined with current stock check.

namespace Local\Dropshipping; use Bitrix\Highloadblock\HighloadBlockTable; use Bitrix\Main\Application; class SupplierResolver { /** * Returns the best supplier for a product: * first the primary supplier with stock > 0, otherwise any with stock */ public static function resolve(int $productId, int $quantity): ?array { $conn = Application::getConnection(); // Find suppliers with sufficient stock $result = $conn->query(" SELECT sp.UF_SUPPLIER_ID, sp.UF_SUPPLIER_SKU, sp.UF_PURCHASE_PRICE, sp.UF_IS_PRIMARY, csp.AMOUNT FROM b_uts_supplier_product sp JOIN b_catalog_store_product csp ON csp.PRODUCT_ID = sp.UF_PRODUCT_ID AND csp.STORE_ID = sp.UF_STORE_ID WHERE sp.UF_PRODUCT_ID = {$productId} AND csp.AMOUNT >= {$quantity} ORDER BY sp.UF_IS_PRIMARY DESC, sp.UF_PURCHASE_PRICE ASC LIMIT 1 "); return $result->fetch() ?: null; } } 

Transmitting the Order to the Supplier

Three transmission channels, in order of preference:

1. Webhook (REST API of the supplier) — the best option. We POST a JSON with order data to the supplier's URL, and they respond with confirmation:

private static function sendWebhook(string $url, string $apiKey, array $payload): bool { $http = new \Bitrix\Main\Web\HttpClient(); $http->setHeader('Content-Type', 'application/json'); $http->setHeader('Authorization', 'Bearer ' . $apiKey); $http->setTimeout(10); $response = $http->post($url, json_encode($payload)); $status = $http->getStatus(); \Bitrix\Main\Diag\Debug::writeToFile( ['url' => $url, 'status' => $status, 'response' => $response], 'Dropshipping webhook', '/local/logs/dropshipping.log' ); return $status === 200; } 

2. Email with an HTML table — when the supplier has no API. Email template via CEvent::Send, event DROPSHIPPING_ORDER_NEW. Table of line items, delivery address, transfer amount.

3. File exchange via FTP/SFTP — for suppliers working with 1C. We generate XML in CommerceML format and place it on the supplier's FTP. They pick it up on schedule.

Stock Synchronization

Stock becomes outdated quickly — the main challenge of any dropshipping schema. Three strategies:

• Push from supplier — the supplier notifies us via webhook on stock change. We implement an endpoint with API key validation.
• Pull on schedule — a Bitrix agent downloads the supplier's feed every 30 minutes and updates stock. Feeds come in XML (1C format), CSV, JSON.
• Reservation — if pull is impossible, we decrease stock in b_catalog_store_product after order creation. Not precise but better than nothing.

Margin Calculation

Purchase price is stored in UF_PURCHASE_PRICE of the HL-block. Retail price is in b_catalog_price. The difference is the margin. A margin report can be queried directly from the database:

SELECT be.NAME AS product_name, cp.PRICE AS retail_price, sp.UF_PURCHASE_PRICE AS purchase_price, cp.PRICE - sp.UF_PURCHASE_PRICE AS margin_abs, ROUND((cp.PRICE - sp.UF_PURCHASE_PRICE) / cp.PRICE * 100, 1) AS margin_pct FROM b_iblock_element be JOIN b_catalog_price cp ON cp.PRODUCT_ID = be.ID AND cp.CATALOG_GROUP_ID = 1 JOIN b_uts_supplier_product sp ON sp.UF_PRODUCT_ID = be.ID AND sp.UF_IS_PRIMARY = 1 WHERE be.IBLOCK_ID = :catalog_iblock_id AND be.ACTIVE = 'Y' ORDER BY margin_pct ASC; 

How Are Supplier Rejections Handled?

A supplier may reject an order (out of stock, address error). We need a status HL-block for tracking:

b_uts_supplier_order

• UF_ORDER_ID — Bitrix order ID (b_sale_order.ID)
• UF_SUPPLIER_ID — supplier ID
• UF_STATUS — pending / confirmed / rejected / shipped / delivered
• UF_SUPPLIER_ORDER — order number at the supplier
• UF_TRACKING — tracking number
• UF_REJECT_REASON — rejection reason
• UF_DATE_UPDATE — last update date

On status rejected, an agent notifies the manager and, if an alternative supplier for the same product exists, automatically redirects the order.

Step-by-Step Setup of Dropshipping

Timelines

What Is Included in the Result

• Data model (HL-blocks Supplier and SupplierProduct) with fields tailored to your suppliers.
• Order router supporting N suppliers with priority-based selection.
• Integration with suppliers: webhooks, email, or FTP — individually for each.
• Near-real-time stock synchronization.
• Rejection handling with automatic redirection to an alternative supplier.
• Architecture documentation and an operations manual.
• Manager training (2 hours) and technical support for 30 days.

Contact us for a free assessment of your task. We will analyze the number of suppliers, order volumes, and existing infrastructure. Order the development of a turnkey dropshipping schema — get a reliable solution that won't break as your business grows.