Automatic population of product images from external sources in 1C-Bitrix

Automatic Image Population in 1C-Bitrix: Where the Exchange Breaks

Exchange with the accounting system is most often checked by product composition: names, prices, stock, properties — everything is in place. Images remain at the tail end of the check, and it is precisely on them that the exchange loses data.

Product export without photos is not detected immediately: cards are created, the catalog fills up, and empty tiles are noticed only by the sales department or the customer.

The first break is at the step of parsing the export file.

The accounting system provides not the file itself but a link to it; if the address is relative, points to an internal resource without external access, or is served with a delay, the exchange module silently skips the image node and writes the product without a picture.

Silently — because for the other fields the exchange is considered successful, and nothing appears in the error report for exchange with the accounting system.

The second break is in the binding. Even when the file is downloaded, it does not attach to the product if the detailed image property in the infoblock does not match the one the exchange writes to, or the record goes to a different trade offer infoblock.

Then manual photo upload is connected — and the first full exchange overwrites what was uploaded manually.

The consequence of this behavior is empty product cards in the catalog, unpredictable filters, and repeated content manager work that is not preserved between exchanges. Plus garbage in media storage: unused copies remain on disk and grow backups. Below we break down how this is closed at each step.

What Automatic Upload Provides: Card Completeness and Publishing Speed

In 1C-Bitrix, automatic image upload is built on linking a product to its source: the SKU or code is matched against the supplier card, and photos are pulled to the required trade offer.

If the supplier nomenclature does not match ours, a mapping table is prepared once — after that it is updated selectively for new items.

Card completeness no longer depends on whether the content manager got to the item. The share of products with images reaches 95–100%: instead of "gray" tiles in search results and on the storefront, the customer sees the product.

The time to publish a catalog with several thousand items is reduced to a single scheduled run — where days of manual export review used to go.

A whole class of errors that is poorly caught manually also goes away: duplicates and different angles of the same SKU, broken links to supplier files, different aspect ratios and image file sizes.

Processing brings them to a unified format, crops the background, and rebuilds previews for the card and mobile listing. The volume of manual operations is reduced to reviewing disputed matches — the rest flows as a stream.

A separate effect is updates: when the supplier changes a photo or adds a new item, the next synchronization pulls the changes itself, without a separate task for the editor and without the risk that the previous image remains on the storefront.

Methods of Automatic Image Population in 1C-Bitrix

The catalog is filled from several sources, and each has its own mechanism for image intake. The choice of method determines what happens on the next update: whether manual edits remain, how quickly the product appears on the storefront, and whether it survives a supplier change.

Below are four options to choose from when configuring the exchange. They are not mutually exclusive, but they require different matching rules and different image quality control.

Comparison of Image Intake Methods

In practice, the methods are combined: the accounting system remains the source of truth for nomenclature, and images are pulled in the way that is more reliable for a specific category.

The main rule is that each image has one record owner: otherwise, on the next exchange, manual edits are overwritten and old or foreign photos appear on the storefront.

Implementation Stages: From Export Parsing to Policy

The order of work is structured so that a data error surfaces before the production exchange, not after it. First, we figure out what actually comes from the accounting system, then we design the link between the product and the image, and only then do we enable regular exchange.

1. Audit of product export. We look at sources, exchange file structure, how image links are passed, and whether there are trade offers. We separately check SKUs: leading zeros, mixed keyboard layouts, extra separators — this is where the main portion of unlinked photos comes from.
2. Matching SKUs and photos. We define the link key and behavior for duplicates, items without photos, and broken links. We define what to do with manually uploaded images: keep or replace.
3. Storage scheme design. We distribute images across infoblock properties, set conversion to a unified card size and sort order so the gallery does not bloat the catalog and does not break the layout.
4. Exchange schedule configuration. The handler takes only changes since the previous run, not the entire catalog; we log every item — it is clear which photos were not linked and why.
5. Test export to a catalog copy. We run the full volume and compare counters: how many items processed, how many linked, how many went to exceptions. We check run time and rollback to the original state.
6. Transfer to the production catalog and policy. The exchange is enabled after reconciliation with no discrepancies; we provide documentation on sources and link keys and configure error notifications.

Handover Package: Exchange Schemes, Matching Rules, Regulations

After implementation, the team retains not only a working exchange but also a set of documents by which the process can be raised again — by an in-house 1C-Bitrix specialist, without contacting the solution authors. Below we list exactly what we capture in the artifacts.

• Data exchange scheme — where files come from (export from the accounting system, supplier catalog, media storage), in what format and at what frequency, where they are stored before publication, and what happens if the source is unavailable.
• Exchange configuration — upload profiles, thumbnail sizes and formats, item limit per run, schedule, and conditions for re-running after a failure.
• Product matching rules — by which key an item is linked to an image (SKU, external code, barcode), how duplicates and products without a code are handled.
• Conflict policy — priority of a manual image over an automatic one, behavior on re-upload, list of rejected files with the reason.
• Instructions for the content manager — how to replace an image manually, how to send an item for an unscheduled update, which processing statuses are visible in the panel.
• Acceptance checklist — share of products with an image after the first run, absence of empty thumbnails, verification on a test group before publishing the entire catalog.

The package lives together with the exchange logic: if the source or matching rules change, the documents are updated in the same change, not as a separate task six months later.

How Manual Photo Upload Went Away: Results on a Live Catalog

Before: Manual Publishing as a Bottleneck

The catalog was assembled manually: the manager exported the nomenclature from the accounting system, downloaded photos from suppliers, brought them to a single form, and attached them to cards one by one.

About six out of ten cards received an image; the rest lived for months with an empty gallery, and a batch of updates was published in 6-7 hours of work.

Recurring errors accumulated: an image was linked to a neighboring SKU, duplicated across several cards, or lost when the product was overwritten. Each such correction was found only after publication — from a customer complaint or during catalog reconciliation.

After: A Rule Instead of a Manual Operation

We described automatic image population in 1C-Bitrix as a set of rules: the image source is determined by supplier, the match to the card by SKU and barcode, and in a conflict the larger and fresher file wins.

New items receive images at the moment of export, while disputed ones go into a separate review queue.

The share of cards with images is 99%, publishing a batch takes 15-20 minutes instead of 6-7 hours, and there are no linking errors left: the rule either finds an exact match or stops the item until a human decides. Catalog reconciliation now takes minutes, not a full working day.

How Catalog Exchange Differs from Import from Supplier Files

These are two different mechanisms, and the difference is not in convenience but in who owns the primary data.

Catalog exchange is scheduled synchronization with the accounting system: products, properties, prices, and an image folder arrive in a single package in CommerceML format.

Supplier file import is parsing a third-party price list in CSV or XLS, where photos are pulled from links in a separate column.

With catalog exchange, the image is linked to the item by the same identifier as the properties, so changing the image does not break the link.

This method is chosen when the nomenclature is maintained in the accounting system and is updated more often than the supplier sends descriptions.

Import is needed where photos live on the supplier's website or in a file storage. Links are downloaded, checked by extension and size, broken ones are rejected, and the image is linked by SKU or product code.

In practice, a combined media intake scheme is more common: the catalog and characteristics come via exchange, while images are gathered by import from supplier files.

Then the choice of photo upload method is determined by a priority rule — what to do if an image is already uploaded and a different one arrives from a new source: keep the manual one or replace it with the automatic one.

Common Technical Questions About Photo Export

Questions about image export boil down to four scenarios: what to do with an outdated or broken source link, how to avoid multiplying duplicates, how many photos to attach to a product, and what will happen to an already manually configured catalog.

Below are short answers for each, without general wording about "configuration flexibility".

How does the export combat image duplicates?

Comparison is by file content, not by name. The same image, placed across ten products under different names, is saved once, and the cards reference a shared resource.

On update, the file is replaced rather than added as new — storage volume does not grow linearly with the number of runs.

Can multiple photos be exported for one product?

Yes, the property is configured as multiple. The order is set by the sort field from the source: the first image goes to the preview and the detail page, the rest go to the gallery.

The quantity limit is set in the exchange rules; excess ones are discarded by priority rather than cut off randomly.

What will happen to products that have already been manually configured?

For them, an "append only" mode is enabled: existing images are not overwritten; only missing ones are added. All changes are written to the exchange log — you can see for which product, when, and what was inserted.

Rollback is done using the same log, so an unsuccessful run does not turn into a manual catalog rebuild.

Let's Discuss the Task: We'll Analyze the Export and Propose a Work Scheme

To come back with an estimate and implementation plan, we need to understand not "how many images to upload" but where they come from and how they are linked to the product.

During the task discussion, we will analyze the export from 1C, the current catalog structure, and how images get to the site today — manually, through an infoblock property, or via a separate file storage. Both the work scheme and the scope of preparatory steps depend on this.

To start, it is usually enough to collect from the customer's side:

• catalog structure: infoblocks, trade offers, properties that already contain links to files;
• image source: export from 1C, a folder on the server, a supplier catalog, or a table with a list of links;
• rule for matching product and image: SKU, external code, barcode, or mapping table;
• behavior on mismatch: skip, put a placeholder, or place in a queue for manual review;
• requirements for the file itself: format, proportions, presence of watermarks, unified background;
• schedule and update volume: one-time upload or regular event-based synchronization.

We separately record access: a test environment, write permissions for the required sections, access to the external source. It is safer to test the scheme on a catalog copy so as not to affect published products.

After that, we will come back with an estimate and implementation plan: we will list the stages, scope of work, control points, and acceptance criteria for the result. Preparing to start work takes less time than subsequently redoing the links between product and image.