Supplier Portal for Dropshipping on 1C-Bitrix
On one project with 60 suppliers, a manager spent 3 hours daily synchronizing stock via Excel. After implementing a supplier portal, that time dropped to 10 minutes. Many dropshipping stores face the same pain: suppliers can't see their orders, update prices via email, and manual entry errors reach 12%. Building a separate personal cabinet for each supplier on 1C-Bitrix solves these issues: isolated permissions, their own products and orders, bulk CSV upload. We automate the routine so a supplier spends 15 minutes instead of 4 hours—and errors approach zero.
Our experience: over 10 years of Bitrix development, 50+ e-commerce projects. We guarantee stable operation of the cabinet under load up to 100 simultaneously active suppliers. We will assess your project within 2 days: contact us for a consultation.
How to Organize Permission Differentiation for Suppliers
In Bitrix, permission differentiation is implemented via user groups. We create a "Suppliers" group through the API:
$groupId = CGroup::Add([
'ACTIVE' => 'Y',
'NAME' => 'Suppliers',
'STRING_ID' => 'SUPPLIERS',
]);
Linking a specific supplier to their products is done via an HL-block SupplierProduct or an infoblock property SUPPLIER_ID of type "Link to user" (E). The supplier cabinet section is protected by checking the group:
if (!$USER->IsAuthorized() || !$USER->IsInGroup($supplierGroupId)) {
LocalRedirect('/auth/?backurl=' . urlencode($_SERVER['REQUEST_URI']));
}
More about user groups in the documentation.
Cabinet Components: Products, Orders, Prices
What's Included in the "My Products" Block?
A list of the supplier's products with current stock and price. Query via CIBlockElement::GetList filtered by SUPPLIER_ID:
$userId = $USER->GetID();
$res = CIBlockElement::GetList(
['NAME' => 'ASC'],
[
'IBLOCK_ID' => CATALOG_IBLOCK_ID,
'ACTIVE' => 'Y',
'PROPERTY_SUPPLIER_ID' => $userId,
],
false,
false,
['ID', 'NAME', 'DETAIL_PAGE_URL', 'PREVIEW_PICTURE', 'PROPERTY_SUPPLIER_ID']
);
For each product, we show current stock from b_catalog_store_product and price from b_catalog_price. Each supplier has their own warehouse (b_catalog_store)—this allows independent stock tracking.
How Does a Supplier Update Prices and Stock?
The supplier sends an AJAX request from a form. The handler checks product ownership and performs the update:
// /local/ajax/supplier-update.php
$productId = (int)$_POST['product_id'];
$newPrice = (float)$_POST['price'];
$newQty = (int)$_POST['quantity'];
$ownerCheck = CIBlockElement::GetProperty(
CATALOG_IBLOCK_ID,
$productId,
'sort',
'asc',
['CODE' => 'SUPPLIER_ID', 'VALUE' => $USER->GetID()]
);
if (!$ownerCheck->Fetch()) {
echo json_encode(['error' => 'Access denied']);
die();
}
$priceRow = CCatalogPrice::GetList(
[], ['PRODUCT_ID' => $productId, 'CATALOG_GROUP_ID' => BASE_PRICE_GROUP_ID]
)->Fetch();
if ($priceRow) {
CCatalogPrice::Update($priceRow['ID'], ['PRICE' => $newPrice, 'CURRENCY' => 'RUB']);
} else {
CCatalogPrice::Add([
'PRODUCT_ID' => $productId,
'CATALOG_GROUP_ID' => BASE_PRICE_GROUP_ID,
'PRICE' => $newPrice,
'CURRENCY' => 'RUB',
]);
}
$storeProductRow = CCatalogStoreProduct::GetList(
[], ['PRODUCT_ID' => $productId, 'STORE_ID' => getSupplierStoreId($userId)]
)->Fetch();
if ($storeProductRow) {
CCatalogStoreProduct::Update($storeProductRow['ID'], ['AMOUNT' => $newQty]);
} else {
CCatalogStoreProduct::Add([
'PRODUCT_ID' => $productId,
'STORE_ID' => getSupplierStoreId($userId),
'AMOUNT' => $newQty,
]);
}
echo json_encode(['success' => true]);
How Does a Supplier See Their Orders?
The supplier sees only orders containing their products. A direct query to b_sale_order is not suitable—we need a link through the basket:
$supplierId = $USER->GetID();
$connection = \Bitrix\Main\Application::getConnection();
$orders = $connection->query("
SELECT DISTINCT
o.ID,
o.DATE_INSERT,
o.PRICE,
o.STATUS_ID,
o.USER_ID,
u.NAME,
u.LAST_NAME,
u.EMAIL
FROM b_sale_order o
JOIN b_sale_basket b ON b.ORDER_ID = o.ID
JOIN b_iblock_element_property ep
ON ep.IBLOCK_ELEMENT_ID = b.PRODUCT_ID
AND ep.IBLOCK_PROPERTY_ID = " . SUPPLIER_PROP_ID . "
AND ep.VALUE_NUM = {$supplierId}
LEFT JOIN b_user u ON u.ID = o.USER_ID
WHERE o.DATE_INSERT >= DATE_SUB(NOW(), INTERVAL 90 DAY)
ORDER BY o.DATE_INSERT DESC
LIMIT 100
");
On the order details page, the supplier sees only their basket items.
Shipment Confirmation and Statuses
The supplier confirms shipment of their part of the order through the interface. Statuses are stored in the HL-block SupplierShipment with fields: UF_ORDER_ID, UF_SUPPLIER_ID, UF_STATUS (pending/confirmed/shipped/delivered), UF_TRACKING, UF_DATE_SHIPPED. When all suppliers for an order have set status shipped, an agent automatically changes the order status in Bitrix to "Shipped".
Bulk Upload via CSV
For suppliers with a large assortment (5000+ items), we provide a CSV upload form with columns: SKU, price, stock. The PHP handler finds the product by CML2_ARTICLE, checks supplier ownership, and updates price and stock if correct. A row limit (up to 5000) prevents PHP timeout. For larger batches, we use background agents.
Comparison of Supplier Management Approaches
| Approach |
Manual Management |
Our Supplier Portal |
| Time to update 100 products |
2 hours |
5 minutes |
| Error risk |
12% |
<1% |
| Data access |
Full admin access |
Only own products and orders |
| Scalability |
Up to 10 suppliers |
100+ suppliers |
Development Stages
| Stage |
Duration |
Outcome |
| Analytics |
1–2 days |
Requirements, prototypes, role model |
| Design |
2–3 days |
DB architecture, component structure |
| Implementation |
5–10 days |
Ready functionality: components, AJAX, integrations |
| Testing |
2–3 days |
Rights verification, load testing up to 100 sessions |
| Deployment & documentation |
1–2 days |
Installation, caching, manager training |
Total timeline: from 1 to 4 weeks depending on complexity (basic cabinet—1–1.5 weeks, full with warehouse and CSV—2–3 weeks, multilingual with analytics—3–4 weeks).
Why Standard Personal Account Doesn't Fit?
The built-in my module in Bitrix is aimed at buyers: shopping cart, order history, personal data. A supplier needs different entities—stock management, bulk upload, shipment tracking. Moreover, without additional configuration, a supplier cannot be restricted to only their products. Hence, a separate component solution with its own permission system is required.
Typical Mistakes We Prevent
- Lack of permission checks on AJAX requests—an attacker could update others' prices. All handlers verify SUPPLIER_ID.
- No tagged caching—with 100 suppliers, page load exceeds 10 seconds. We use caching with user tags.
- Supplier warehouse not created automatically—all suppliers' stock get mixed. We create a warehouse upon supplier registration via the OnBeforeUserRegister event.
Benefits of Automation
Automated data exchange with suppliers is 5 times faster than manual entry. Errors in manual updates occur in 12% of transactions—with our portal, this rate approaches zero. Each supplier saves at least 3 hours per day on stock reconciliation.
Get a consultation on cabinet architecture—describe your situation, and we will offer the optimal solution. Order a turnkey supplier portal and start accepting orders in 1–2 weeks.
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.