Automatic stock collection from supplier storefronts in 1C-Bitrix
Situation: the supplier does not provide an API, sends price lists once a week by email, and actual stock changes daily. A customer places an order — the product is out of stock.
We solve this problem by parsing the supplier's storefront and updating the CATALOG_QUANTITY field in 1C-Bitrix. Parsing is not always HTML: often stock is stored in JSON variables on the page (window.__PRODUCT_DATA__).
We use CURL and regex — this is faster than a headless browser and does not load the server. To protect against blocks, we use random User-Agents and proxy rotation. Over 5 years on the market, we have automated stock collection for catalogs from 500 to 50,000 SKU.
Each project undergoes individual configuration — from choosing the parsing method to the logic for handling zero stock. Order parsing development — and we will analyze your supplier's storefront.
How we parse stock from supplier websites
On a supplier's website, stock can be represented in different ways: a numeric value (in stock: 47 pcs) — we parse the number directly; a stock status (in stock, on order, out of stock) — we map it to 0/1/999; multiple warehouses — we sum them or take the nearest warehouse.
Sometimes stock is hidden in JS variables — we search via regex in the page body, which is faster than a headless browser. If the supplier uses an API (rarely), we connect via REST.
Why is product mapping the biggest bottleneck?
This is the key stage. Without reliable mapping, parsing is useless. Options:
- Supplier SKU — we add a
SUPPLIER_SKUproperty to the infoblock. During parsing, we search for the element with this value viaCIBlockElement::GetList()with a filter by property. - XML_ID — if products were previously imported from the supplier's price list, XML_ID may match their internal ID.
- EAN/barcode — a universal option for branded products.
For large catalogs (10,000+ SKU), filtering by property via ORM works slowly. It is better to build a reverse mapping supplier_sku → element_id in Redis or in a custom table and update it when the catalog changes.
How stock is updated in Bitrix
According to the 1C-Bitrix documentation, updating product quantity is performed via the CCatalogProduct::Update method.
CCatalogProduct::Update($elementId, [ 'QUANTITY' => $parsedQty, 'QUANTITY_RESERVED' => 0, ]);
If the store uses warehouses (b_catalog_store), we update via CCatalogStoreProduct::Update() specifying STORE_ID.
When updating only quantity, do not touch ACTIVE — otherwise you will lose manual activity edits. Perform a separate UPDATE of only the required field.
How to handle zero stock without losing sales?
You should not automatically hide a product when stock is zero — the supplier may restock the warehouse the next day. The correct gentle logic:
- Quantity = 0 → the product remains active, but a "on order" flag is added.
- Quantity = 0 for more than N days → notification to the manager, manual decision.
- Product not found on the supplier's website 3+ times in a row → flag
SUPPLIER_DISCONTINUED.
We implement flags via infoblock properties or Highload block fields.
How to set up stock parsing: step-by-step instructions
- Analysis of the supplier's storefront. We determine the parsing method (HTML, JSON variables, API) and prepare selectors.
- Parser development. A PHP script with CURL, regex support, optionally Guzzle. To protect against blocks, we use random User-Agents and proxies.
- SKU mapping setup. Linking supplier SKUs with product IDs in Bitrix. For catalogs of 10,000+ SKU, we use Redis.
- Integration into Bitrix. An agent or cron job, stock updates via
CCatalogProduct::Update(). We test on a test set of products. - Zero stock handling logic. Automatic flags, notifications to the manager. We test scenarios: product disappeared, appeared, price changed.
- Monitoring and support. After launch, the parser works stably; if the supplier's website structure changes, adaptation takes no more than a couple of hours.
What is included in the work
| Component | Description |
|---|---|
| Analysis of the supplier's storefront | We determine the parsing method (HTML, JSON variables, API) and prepare selectors |
| Parser development | A PHP script with CURL, regex support, optionally Guzzle |
| SKU mapping | Linking supplier SKUs with product IDs in Bitrix |
| Integration into Bitrix | An agent or cron job, stock updates via CCatalogProduct::Update() |
| Zero stock handling logic | Automatic flags, notifications to the manager |
| Documentation and support | Mapping scheme, instructions for adding a supplier, 2 weeks of free support |
Work timeline
| Stage | Duration |
|---|---|
| Analysis of the supplier's website, choosing the parsing method | 2–4 hours |
| Stock parser development | 1–2 days |
| SKU mapping setup | 4–8 hours |
| Update logic in Bitrix + zero stock handling | 4–8 hours |
| Schedule and monitoring setup | 2–4 hours |
Total: 3–5 business days per supplier. Each additional supplier — +1–2 days (different website structures).
We guarantee that after launch, parsing will work stably, and if the supplier's website structure changes, adaptation will take no more than a couple of hours. Time savings on manual stock processing — up to 80% per month. We will evaluate your project — just write to us. Let's discuss the task right now.