Data parsing from Yandex.Market for 1C-Bitrix

Parsing Yandex.Market for a 1C-Bitrix catalog: what breaks

The marketplace updated prices overnight, but the storefront on 1C-Bitrix remained at the previous values: the customer places an order at a price that no longer exists, and the manager sees stock that does not match the real warehouse.

This is not a one-off failure but the normal behavior of a catalog without regular exchange — Yandex.Market parsing turns into a set of manual operations, whereas it should be part of the data flow.

The cause is usually the same: items are matched by name. The supplier edits the name for every advertising campaign, and the link breaks — duplicates appear, and some products are updated against the wrong offers. A reliable key is the SKU and barcode, while the name and description remain editable fields.

Updating prices and stock in a batch without a log, when the connection drops, leaves half the catalog with old values: the next export starts from the beginning and does not catch up with the lagging items.

This is also where manual card edits come from — a manager edits a title or property, and the next import overwrites it because editorial content is not separated from supplier data.

The chain is closed by a mismatch between the catalog and the marketplace on availability: out-of-stock products remain active and go to cancellation, while the cache and search index keep the old value for another day. Next, we look at how this is closed on the Bitrix side.

What regular product data exchange with a marketplace provides

A one-time catalog collection solves the task for a day, after which prices and stock again diverge from reality.

Regular exchange with Yandex.Market is built as a scheduled job: the system itself picks up product changes and returns updated prices and availability, leaving only exceptions to people.

The first measurable effect is the share of items with an up-to-date price. With manual price list edits once a week, it sags by the end of the interval and is always uneven: some cards drift away, and restoring the picture without reconciliation is impossible.

Exchange on a schedule and only for changed SKUs keeps the share of current prices near the upper bound, while a mismatch for a specific product lasts minutes rather than days.

The second effect is time spent preparing the export.

Price list reconciliation, duplicate cleanup, and manual editing of descriptions and characteristics are collapsed into a one-time field mapping: the update schedule performs the same work based on the exchange log rather than the manager's memory. The freed hours go to cards and prices that genuinely require a human decision.

The third is the class of failures due to incorrect availability. Selling an item that is not in stock results in order cancellation and a drop in the seller's rating.

Scheduled stock exchange, buffer stock for fast-moving SKUs, and a separate "out of stock" status instead of a zero price remove this category of errors almost entirely.

Exchange does not replace the accounting system — it keeps the marketplace in agreement with it. Below, we look at how data parsing works and where it breaks most often.

Parsing formats: one-time import, schedule, update stream

The collection format determines not the convenience of work but the acceptable mismatch between the site catalog and the marketplace card.

Yandex.Market data can be fetched one-time, on a schedule, as a stream, or through the marketplace's official interface — each option has its own failure class and collection constraints. Below is a comparison that is usually used to choose a scheme.

The choice is not the "fastest" option but a combination: a one-time export sets the base, the schedule maintains currency, and the stream covers critical items.

Then matching decides — we link products by SKU and barcode so that updates do not breed duplicates in information blocks and discrepancies go into a report. Describe the task — we will come back with an estimate and a plan for your case.

Implementation order: from catalog audit to handover of schedules

1. Catalog audit. We reconcile nomenclature, offers, and properties, look for duplicates, items without external identifiers, and products that exist in the catalog but have already been withdrawn from sale by the supplier. The output is a mapping table and a list of places that the exchange will break.
2. Exchange scheme. We determine flow directions, launch frequency, behavior on mismatch, and limits on the volume of changes per run. The scheme is fixed in writing before the first line of code.
3. Matching rules. The primary key is an external identifier; the fallback is SKU and normalized name. Separately, we describe the creation of new items, archiving of disappeared ones, and price priority: from the card or from the price list.
4. Exchange setup. We implement the exchange in 1C-Bitrix, set up scheduled jobs, and connect a log: each run writes a report with the number of created, updated, and rejected items.
5. Testing on a copy. We run it on a copy of the production catalog and a copy of the database: repeated launch, connection loss, empty response, partially incorrect data. Rollback must be a standard operation before release.
6. Handover of schedules. Instructions for the content manager: how to read the report, what to do with mass rejections, how to add a category. Plus a run log and notifications so that a failure is found before a customer complaint.

What you keep: exchange schemes, matching rules, schedules

After launching Yandex.Market parsing, what you keep is not one-time exports but a working exchange loop: schemes, rules, and documents that the team uses to continue work without the original author.

This is the main acceptance criterion — the system can be handed to another engineer or put into support without reconstructing the logic from chat messages.

• Data exchange scheme — a route map "source → intermediate table → catalog card" with a list of fields for each step: what is always updated, what is only added, and what is never overwritten.
• Product matching rules — key priority (manufacturer SKU, then barcode, then "brand + model" combination), with separate branches for sets, kits, and items with variants.
• Error log — records the failure type, time, source record, and a flag "retry automatically or send to manual review"; discrepancies are not swallowed silently but enter a queue with a clear status.
• Update schedule — launch frequency for prices and stock, procedure when the source is unavailable, and rules for rolling back to the previous catalog snapshot.
• Editor instructions — which properties are edited manually and which will be overwritten on the next synchronization, so manual edits do not disappear without a trace.
• Configured checks — control of duplicates, empty prices, and anomalous spikes: changes pass validation and do not enter the production catalog until confirmed.
• Access and handover point — where configurations are hosted, who is responsible for the schedule, and how to transfer the loop to a new contractor.

Each item is agreed with your team at the launch stage and tested on a real export — you do not need to guess how the exchange will behave the next time the output changes.

Case study: removed manual price and stock updates in the catalog

A catalog with 12,000 items relied on manual work: editors once a week merged exports from three sources, reconciled line by line by SKU, and uploaded the update to the site.

Price and availability mismatches reached 20% — the customer saw current data only at the moment of checkout, and "out of stock" cancellations hurt conversion and the store's reputation.

Preparing the price list took 12–14 hours a week, that is, several full working days of an editor per month on mechanical reconciliation instead of working with descriptions and categories.

An error in one line did not surface immediately: it was noticed only from a customer inquiry, when the item had been sitting with incorrect stock for weeks.

We built a data flow from Yandex Market to the catalog: matching by SKU and barcode, priority rules, an exchange queue with a log for each item, and rollback to the last correct state if the source fails.

Disputed rows do not silently overwrite prices but are put into a separate list with a reason — the editor reviews only those.

Updates run every 30 minutes for price and stock and once a day for categories and characteristics.

The mismatch rate fell below 1%, about 3% of items require manual intervention, and the editor's workload dropped to 40 minutes a day: they check exceptions rather than reconcile tables.

Availability cancellations decreased severalfold, and cards stopped diverging from the real warehouse.

What to do if the catalog is already synchronized by a third-party module?

A third-party exchange module is usually a black box with its own mapping table and its own schedule. It cannot be removed immediately: doing so would take away the accumulated product-to-section binding, and some fields are filled only by it.

The first step is not replacement but telemetry collection: how many records the cycle affects, which card properties it overwrites, and by which key it matches a product.

Next is a data correctness check. We take a catalog slice and reconcile SKUs, prices, stock, offers, and section binding with the source.

Separately, we look at duplicates and items that no longer exist in the source: the module marks them as withdrawn from sale rather than deleting them, and this behavior must be preserved — otherwise we will get broken links in sections.

Update conflict is resolved by separating field ownership: price and stock remain with the exchange; description, photos, and tabs remain with the editor.

Without this, two schemes overwrite each other's edits, and this becomes noticeable only from the change history of a specific card, that is, after content has already been lost.

Zero-downtime migration runs in parallel: the new channel is brought up next to the old one and writes to the same entities through separate service properties. We compare several full cycles by the number of changed items and discrepancies, and switch over only after they match.

Rollback of changes remains reversible: while reconciliation is running, we keep a dump of the catalog and mapping tables, so returning to the previous scheme is one operation, not restoration from an old backup.

Technical concerns: matching, duplicates, request limits

The review of technical concerns begins with the fact that exchange stability is built into the scheme at the design stage, not fixed manually after every export.

The matching key, name normalization rules, and request schedule are described before the first launch — that is why a repeated exchange updates the catalog rather than creating it anew.

Below are the questions that most often come up at the start: how items are linked, what happens to card duplicates, and how the exchange behaves under rate limits.

What will happen to card duplicates during regular exchange?

Deduplication uses the same key: a repeated export updates the existing card rather than creating a second one. If a product comes from several sources, offers are merged into one card while preserving change history.

Items that are no longer current at the supplier are marked as withdrawn from sale rather than deleted — this preserves the link to orders.

Will we hit the source's request limits?

The exchange runs on a schedule with pauses between requests and caching of unchanged sections. If a rate-limit response is received, the exchange pauses and continues from the same item, while retries use increasing delay.

The log records every operation, so a failure in the middle of an export does not result in a partially updated catalog.

Let's discuss the task: what to prepare for the conversation and what you will get

To make the conversation about Yandex.Market parsing specific rather than "general," it is enough to prepare a few catalog inputs for it.

The more accurately they are described, the fewer assumptions there are in the timeline estimate and the more concrete the work plan becomes. Below is what actually affects the scope of work.

• Source and destination. The Marketplace section or list of categories from which we take cards, and where they land in 1C-Bitrix: offers, properties, catalog sections.
• Matching rules. By which field we link a product to an existing item — SKU, barcode, name with model; what we do when two sources give different values.
• Card composition. Which fields are needed: price, characteristics, gallery, description, stock; what updates frequently and what only needs to be loaded once.
• Update schedule. Manual launch, scheduled, or on change; what happens to a product that disappeared from the output.
• Access and limitations. Whether there is official programmatic access to the data or we work through exports, what the request rate limits are, and who on the customer side confirms the rules.
• Owner for disputed cards. Who handles edge cases and through which channel we agree on changes to the rules.

Describe the task in free form and attach what you already have — we will come back with an estimate and a work plan: stages, testing on a test set of cards, and a rollback option if the matching rules have to be revised.