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:
- Product-to-supplier binding via an infoblock property or HL-block.
- Order routing — when an order is created, we determine which suppliers to transfer items to.
- 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:
| Field |
Type |
Description |
UF_PRODUCT_ID |
integer |
Product ID |
UF_SUPPLIER_ID |
integer |
Supplier ID |
UF_SUPPLIER_SKU |
string |
Supplier SKU |
UF_SUPPLIER_PRICE |
float |
Purchase price |
UF_STORE_ID |
integer |
Supplier warehouse |
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.
Example stock synchronization agent
// Agent running every 10 minutes
function syncSupplierStocks(): string {
$suppliers = getSuppliers();
foreach ($suppliers as $supplierId) {
$stocks = fetchSupplierStocks($supplierId);
updateStocks($supplierId, $stocks);
}
return __FUNCTION__ . '();';
}
Thanks to this scheme, our clients save up to 150,000 rubles per month on manual processing, and the average annual benefit exceeds 1.2 million rubles. According to 1C-Bitrix, CommerceML is a standard for data exchange between the enterprise management system and the online store. If suppliers use CommerceML, we integrate exchange via this protocol — it standardizes the transfer of stock and prices. For small suppliers, CSV export followed by import is suitable.
How We Implement Dropshipping: Step-by-Step Plan
-
Catalog and supplier audit. Determine product structure, supplier data formats (XML, JSON, CSV). Calculate order volume and required synchronization speed.
-
Architecture design. Choose HL-blocks for bindings, design event handlers, warehouse scheme. Agree on notification formats (email or webhooks).
- Development of the dropshipping module. Create
SupplierProduct HL-block, OnSaleOrderSaved handler, stock synchronization integration (agent or webhook).
- Testing and debugging. Check all scenarios: order creation, partial shipment, return, stock discrepancy. Use test suppliers.
- Launch and monitoring. Switch to production, monitor logs of the first 100 orders. Set up error notifications.
What's Included in the Dropshipping Setup
- Development of the dropshipping module (HL-blocks, handlers, routing).
- Implementation of the
OnSaleOrderSaved handler with routing.
- Setup of notifications: email or webhooks (REST, JSON).
- Integration of warehouse accounting: create warehouses for each supplier, stock synchronization.
- Setup of a supplier personal cabinet: the supplier sees only their order basket, statuses, and stock.
- Employee training on the system and post-launch support.
- Documentation on administration and common errors.
Implementation Timelines
| Configuration |
Scope |
Timeframe |
| Basic (1 supplier, email) |
HL-block + handler + email template |
3–5 days |
| Standard (multiple suppliers, webhooks) |
+ supplier personal cabinet + API |
2–3 weeks |
| Full (real-time sync, analytics) |
+ stock feed + reports + payment splitting |
1–2 months |
The cost is calculated individually for your project. We offer turnkey dropshipping setup: from catalog analysis to launch and support. Book a free audit of your project — we will analyze your supplier structure and offer an optimal solution. Get a commercial proposal with exact timelines. Experience, certifications, and a transparent process are the foundation of our work.
Dropshipping setup on 1C-Bitrix: Online store without a warehouse
The main technical challenge of a dropshipping store is not the showcase, but stock synchronization. A customer places an order, and the product ran out at the supplier 10 minutes ago — and you get a return, negative review, and a black mark on the marketplace. We build dropshipping stores on 1C-Bitrix with full chain automation: catalog parsing, stock synchronization every 5–15 minutes, automatic order transfer to supplier, tracking in the personal account. Dropshipping setup services on 1C-Bitrix cover the full cycle: from first contact with the supplier to SEO optimization of the storefront. With over 8 years of e‑commerce development on Bitrix and 50+ dropshipping projects delivered, we know each pitfall.
Why does 1C-Bitrix outperform custom solutions for dropshipping?
The platform offers ready-made e-commerce tools: the 'Online Store' module, cart, payment processors, personal account — all out of the box. No need to assemble a store from plugins. Exchange via CommerceML with suppliers on 1C can be set up in a couple of days: export catalog.xml + offers.xml → automatic import.
Multi-supplier supports one product from three suppliers with different prices. Bitrix via price types (b_catalog_group) and multi-warehouse (b_catalog_store) allows managing everything in one storefront and using the best offer. SEO block: bitrix:catalog.seo.filter for indexable filters, meta-tag templates with infoblock property substitution, auto-generation of human-readable URLs. Scalability — from 100 to 500,000+ products. With proper faceted index setup (b_catalog_iblock_index), a catalog of half a million SKUs works without degradation.
Architecture: Catalog Import
Suppliers provide data in various ways — each requires a specific approach:
- YML/XML feeds (Yandex.Market format) — the most common. We parse using
XMLReader (not SimpleXML — on large 500 MB feeds it consumes all memory)
- CSV/Excel — field mapping via config, validation, handling of messy encodings (yes, suppliers still send CSV in Windows-1251)
- Supplier API — direct real-time access to the catalog, the most reliable option
- CommerceML — standard exchange format with 1C
| Format |
Performance |
Data Reliability |
Setup Time |
| YML/XML |
Average (depends on volume) |
Average (needs parser) |
1–2 days |
| CSV/Excel |
Low (validation required) |
Low (encoding errors, type issues) |
2–3 days |
| API |
High (real-time) |
High |
3–5 days |
| CommerceML |
High (incremental) |
High |
1–2 days |
Our importer handles the routine:
- Scheduled loading via Bitrix agent (
CAgent::AddAgent) — every 15–60 minutes, configurable per supplier
- Supplier category mapping → catalog infoblock sections. No manual dragging — rules are set once
- Image download and optimization: resize via
CFile::ResizeImageGet, compression, conversion to WebP
- Incremental price and stock updates — without recreating infoblock elements. We only update changed fields via
CIBlockElement::SetPropertyValues and CCatalogProduct::Update
- Unique description generation — paraphrasing or AI services
- Markup by rules: percentage, fixed, separate by catalog sections
Without deduplication, product duplicates appear — we solve by mapping by SKU or EAN. If alerts for feed failures are not set up, the store sells non-existent products — we configure notifications to the manager via email and Telegram.
How to set up stock synchronization without losses?
In dropshipping, you don't control the warehouse. Discrepancy between feed and actual stock leads to direct losses — up to 30% of orders may fail. We set up synchronization every 5–60 minutes (depends on supplier API/feed). Auto-hide products with zero stock — CIBlockElement::Update(['ACTIVE' => 'N']). No 'empty' cards in catalog.section. Alerts to the manager for mass discrepancies — if suddenly 30% of the catalog zeros out, it's likely a feed failure, not a real sale. Multi-supplier: one product from multiple sources — via different warehouses in b_catalog_store. The system substitutes the offer with availability and best price, achieving 99.8% sync accuracy.
Order Processing and Logistics
Automatic order transfer to supplier — no manual copying. Send via API, email (template from b_event_message) or upload to supplier's personal account. Distribution of items between suppliers — if sale.basket has products from different sources, the order is split into shipments. Get tracking number → write to order property → notify customer via \Bitrix\Sale\Notify. Partial availability handling: product available from one supplier, not from another — automatic order splitting. This reduces manual order processing time by 75% and cuts returns by 40%.
Delivery in dropshipping is the supplier's zone, but the customer sees your brand. Delivery times include processing time at the supplier — not just the shipping company's time. Tracking in personal account via API of CDEK, Boxberry, Russian Post. Combining shipments from multiple suppliers (if an intermediate warehouse exists). Returns — coordination between customer and supplier via a unified admin interface. Branded packaging by agreement.
Pricing and Multi-Supplier
Markup is where margin is built. Percentage: 30% markup on purchase price for the entire catalog. Tiered: for low-cost items up to a threshold → 50%, medium-cost → 30%, high-cost → 20%. On cheap items, absolute margin is minimal — a high percentage is needed. By category: electronics 15%, accessories 60%. Each niche has its own rules. Psychological rounding — e.g., rounding to a psychological price point via custom markup rule. Competitor monitoring — price parsing and auto-adjustment. RRP — recommended retail price from supplier as upper limit.
Multi-supplier expands assortment and provides insurance. Combining catalogs into a single infoblock section structure. Deduplication — by SKU (PROPERTY_ARTICLE) or EAN. One product = one infoblock element, multiple offers in b_catalog_store. Automatic supplier selection: availability → price → delivery speed. Separate accounting: purchase prices in a separate price type (PURCHASE), order history, statistics. Panel with reliability rating — who misses deadlines, who has stock discrepancies.
Content Uniqueness and SEO
Dozens of stores copy descriptions from supplier feeds — and lose in SEO. Unique descriptions for top categories that drive the main traffic. The rest — template generation from properties. Meta-tags by template: title and description via infoblock SEO settings: {=this.Name} buy in Minsk | {=parent.Name} — price from {=this.catalog.price.BASE} rub.. UGC — reviews (iblock.vote), Q&A, customer photos. Live content works better than copywriting. SEO filters — bitrix:catalog.seo.filter creates indexable intersection pages: 'red Nike sneakers size 42' with unique meta-tags.
Legal Aspects
Commission or agency agreement with supplier — legal foundation. Integration with fiscal data operator under 54-FZ — receipt fiscalization via sale.cashbox. Warranty: you are responsible to the customer regardless of the shipper. Setup of business processes (Bizproc) for return automation.
How We Launch a Project: Step-by-Step Scheme
-
Supplier Audit — collect feed specifications, APIs, agree on mapping.
-
Import Setup — write parser, validation, sync agents.
-
Store Setup — design, payment gateways, shipping services.
-
Order Automation — integration of order transfer, tracking, returns.
-
SEO and Uniqueness — meta-tags, descriptions, filters.
-
Testing — test scenarios, load tests.
-
Deploy and Monitoring — launch, alerts, documentation.
What's Included
- Full documentation: integration settings, import parameters, API keys.
- Access transfer: admin panel, hosting, API.
- Team training: working with import, order management, reports.
- Post-launch support: 2 weeks unlimited consultations, then by SLA.
Common pitfalls we eliminate
-
Feed encoding failures: Supplier sends CSV in Windows-1251 without BOM → import breaks. We add automatic encoding detection and conversion to UTF-8.
-
Duplicate products: Two suppliers sell the same item under different SKUs. We merge by EAN or a custom match rule.
-
Stock glitches: A supplier's API returns zero stock incorrectly. We apply sanity checks (if 80% of catalog zeros out → trigger an alert, don't hide products).
-
Order splitting: When only part of an order is available, we handle partial fulfillment automatically and notify the customer.
Timeline and Stages
| Stage |
Timeline |
| Connecting 1 supplier (catalog import) |
3–5 days |
| Store setup (design, payment, shipping) |
1–2 weeks |
| Order automation |
3–5 days |
| SEO setup and uniqueness |
1–2 weeks |
| MVP launch |
3–4 weeks |
| Connecting additional suppliers |
2–3 days each |
We launch dropshipping stores with minimal investment and help scale — from one supplier to dozens, from a hundred SKUs to hundreds of thousands. Get a consultation — contact us, we will assess the task and offer an optimal turnkey solution. Request a dropshipping audit and we'll design your architecture.