Your parser gathered 40,000 products from a marketplace, but import into 1C-Bitrix ended with errors? The standard import module can't handle category hierarchies, pull images by URL, or map dynamic attributes. We've encountered this dozens of times — and developed a reliable integration algorithm. We build an adapter that turns raw data into a correct Bitrix structure. We handle turnkey integration: from mapping to update schedule setup. Over 5 years we have implemented 50+ such integrations for large catalogs.
A typical scenario: Bitrix's native CSV import doesn't support element queues, causing performance drops. Importing 40,000 products takes 2 hours with 30% errors. A data import adapter solves these problems in a single run — time drops to 20 minutes, errors below 1%.
How the import module works in Bitrix
Native catalog import uses the catalog module and the bitrix:catalog.import.csv component. According to official documentation for 1C-Bitrix, standard import is not designed for complex category structures. Tables involved:
-
b_iblock_element— infoblock elements (products) -
b_iblock_element_prop_s*/b_iblock_element_prop_m*— property values -
b_catalog_price— prices -
b_catalog_product— product parameters (weight, dimensions, type)
Standard CSV import via CIBlockElement::Add() and CIBlockElement::Update() is functional but does not scale beyond 10,000 products: each call makes a separate database query.
Where naive integration breaks
Case. A parser collects 40,000 products from a marketplace, writes a CSV with columns name, price, category_path, images[], attrs{}. Running standard import completes in 2 hours with 30% errors:
- Categories are created as a flat list instead of a tree, because the parser writes the path as a string "Electronics / Smartphones / Apple" and the importer doesn't parse hierarchy.
- Images are not pulled — the parser sends URLs, the importer expects a local path or base64.
- Properties (attributes) are ignored — CSV import does not support dynamic columns.
How the adapter solves category normalization?
The adapter parses the category string, recursively creates sections via CIBlockSection::Add(). The path → section ID mapping is cached in b_iblock_section to avoid recreating existing ones. For 40,000 products with category depth up to 5 levels, this operation takes about 10 minutes — 6 times faster than piecemeal creation.
Why batch writing is critical?
Batch writing via transaction is 10 times faster than piecemeal addition. Instead of CIBlockElement::Add() in a loop, we use an event-driven model and queues:
// Disable search and events during import CIBlock::DisableOptimization(); $GLOBALS['BX_DONT_WRITE_INDEX'] = true; // Batch of 500 elements via transaction $DB->StartTransaction(); foreach ($batch as $item) { $el = new CIBlockElement(); $el->Add($fields, false, false, false); } $DB->Commit(); After import, rebuild the search index: CSearch::ReIndexAll() or the agent bitrix:search.reindex.
Comparison: Native import vs adapter
| Characteristic | Native import | Adapter |
|---|---|---|
| Import time for 40,000 products | ~2 hours | ~20 minutes |
| Errors | up to 30% | less than 1% |
| Categories | flat list | hierarchy |
| Images | not supported | download by URL |
| Properties | static only | dynamic mapping |
Detailed adapter workflow
The adapter receives data from the parser, goes through the following stages:
- Data reception (CSV/JSON/XML) via file or API.
- Parsing and validation: discard records with incorrect fields.
- Category normalization: parse path, create sections.
- Property mapping: match parser attributes with infoblock.
- Batch write to infoblock using transactions.
- Image processing: download by URL, attach to product.
- Report generation and search index rebuild.
How to set up the adapter in 3 steps?
- Create field mapping. Specify which parser field corresponds to name, price, category, and properties. If the parser adds new attributes, the adapter automatically extends the infoblock.
- Check categories. Run a trial normalization: the adapter creates a section tree from the path string. Results can be reverted if categories don't match.
- Run a test import. Import 100-200 products, verify data correctness and no duplicates. Then run the full import.
Synchronization on updates
The external product ID (SKU or source URL) is stored in the EXTERNAL_ID property or in the element's XML_ID. Before creation, we check existence via CIBlockElement::GetList(['=XML_ID' => $externalId]) — update existing or create new. No duplicates.
What's included in the integration?
| Stage | What we do | Result |
|---|---|---|
| Analysis | Study parser structure, field mapping | Mapping schema, documentation |
| Development | Write adapter, category and image processing | Adapter code, migration code |
| Testing | Run on real data (1000+ items) | Error report, fixes |
| Deployment | Configure schedule, monitoring, training | Agents, logs, instructions |
We also provide a documentation package, repository access, and one month of support after launch.
Schedule and monitoring
Recurring parsing is triggered via Bitrix agents (b_agent) or system cron. The agent calls the adapter, which logs the result into a custom infoblock: date, number of processed/error records. If errors exceed 5%, an admin notification is sent via CEvent::Send(). The error threshold is configurable. After import, we enable tagged caching to speed up catalog loading.
Typical timelines
Timeline evaluation is individual for each project, but as a guide: from 1 to 3 working days for a standard integration. We guarantee error-free import and provide a test run on your data.
Get a consultation — we'll evaluate your project in one day and provide a roadmap. Order the parser-to-Bitrix integration without the headache.