Automated Catalog Sync with Ozon, Wildberries, Yandex.Market

Automated Catalog Synchronization with Ozon, Wildberries, Yandex.Market

Automated catalog synchronization with Ozon, Wildberries, and Yandex.Market solves the problem of product desynchronization. Imagine: you have 5000 SKUs, three marketplaces, and managers manually edit descriptions and prices. After a month, there is desynchronization: on Ozon the product is missing, on Wildberries the price is outdated, on Yandex.Market the photo is wrong. Every day, managers spend hours checking cards, and clients complain about duplicates and incorrect stock. This situation is familiar to many: according to our statistics, manual catalog management on three platforms takes up to 20 hours per week and results in 15–20% erroneous cards. Our team of engineers with over 7 years of experience in e-commerce has implemented more than 50 projects for integrating catalogs with marketplaces. The system automatically transfers new products, updates changes, and removes deleted items — without manual effort. We use a change detector based on hashing, which allows processing 10,000 products in 15 minutes — 5 times faster than full enumeration.

According to Ozon documentation

Why Manual Synchronization Doesn't Work?

Each marketplace has its own data format: Ozon requires a unique identifier in the offer_id field, Wildberries uses article, Yandex.Market — its own SKU. Categories and attributes differ: on Ozon you need to specify a product type (e.g., 'Shoes' in category 17032750), while on Wildberries you need to link to a subject. Manual mapping of 5000 products takes a week and gives 20% errors. Automation with our mapper reduces time to 3 hours and errors to 1%.

How Does Change Detection Work?

We use field hashing: name, description, brand, price, images, dimensions. On each product update in your CMS or ERP, a SHA-256 hash is computed and compared with the stored one in the marketplace_product_mappings table. If the hash differs — the product goes into the sync queue. This reduces load on marketplace APIs: a typical store with 10,000 products and 100 changes per day makes only 100 requests instead of 10,000. For speed, we use Laravel Horizon queues with delays between requests to stay within limits (e.g., Wildberries — 1 request/sec).

Why Category Mapping Is a Bottleneck?

Without category mapping, it's impossible to upload a product: each platform has its own tree. We store mappings in the database and provide a UI for linking. For Ozon we use category search by name via API. For Wildberries — manual mapping with autocomplete. Example:

class CategoryMapper
{
    public function getMarketplaceCategory(int $siteCategoryId, string $marketplace): ?int
    {
        return DB::table('category_mappings')
            ->where('site_category_id', $siteCategoryId)
            ->where('marketplace', $marketplace)
            ->value('marketplace_category_id');
    }

    public function suggestOzonCategory(string $categoryName): array
    {
        return Http::withHeaders($this->ozonHeaders)
            ->post('https://api-seller.ozon.ru/v1/description-category/search', [
                'language' => 'DEFAULT',
                'query'    => $categoryName,
            ])
            ->json('result');
    }
}

Process: From Audit to Deployment

1. Analysis — we break down current integrations (CMS, ERP, marketplace APIs).
2. Design — data schema, mapping, task queues (Laravel Horizon + Redis).
3. Implementation — we write adapters for each marketplace using the REST API.
4. Testing — we test on a catalog copy: change detection, error handling, load.
5. Deployment — we deploy on your server or cloud (AWS, Vercel).

What's Included in the Final Solution?

In addition to adapters, we supply a monitoring dashboard based on Laravel Telescope. It shows counts of active, pending, and erroneous products per marketplace. If the error count exceeds 5% of total products, the system sends a notification to Telegram or Slack. We also configure logging of all operations in the sync_logs table for audit.

-- Current catalog state per marketplace
SELECT
    marketplace,
    COUNT(*) FILTER (WHERE status = 'active')  AS active,
    COUNT(*) FILTER (WHERE status = 'pending') AS pending,
    COUNT(*) FILTER (WHERE status = 'error')   AS errors,
    MAX(last_synced_at) AS last_sync
FROM marketplace_product_mappings
GROUP BY marketplace;

Timeline and What's Included

Total: 18–24 business days. Warranty support — 1 month after delivery. The cost includes documentation, dashboard setup, and employee training. Such automation saves from 30,000 to 50,000 rubles monthly on manual management.

Marketplace Requirements Comparison

Typical Synchronization Errors

Incorrect category mapping — product goes to wrong category. Solution: upload a test batch and manually verify.

API rate limit exceeded — marketplaces block requests. Solution: queue with delays and retry after 5 minutes.

Different image formats — platforms require specific dimensions. Solution: configure compression presets.

Get a consultation on catalog automation today. Contact us and we will prepare a custom solution.

How to Avoid Discrepancies in Commission Calculations

Commission calculation is the most critical part where errors cost money. Rule one: never store commission as a derived value, always as a fact. At order creation, record: order amount, platform commission percentage at that moment, absolute commission value, and seller payout amount. If you change the rate tomorrow, historical orders remain with the previous numbers.

Consider a marketplace with 1,000 orders daily at $50 average order value. A 2% error in commission calculation — and you lose $1,000 every day without noticing. Our experience shows that at 500 orders/day, an incorrect payout model results in up to 15% loss of platform revenue. We have solved this for 50+ projects, from niche B2B to horizontal retail. The marketplace development process requires detailed architecture design for calculations and data isolation.

Commission Models (we use one of or combine)

We use Stripe Connect as the baseline standard. Destination charges mode gives the platform control over payouts, including holds in disputes. Seller onboarding goes through Stripe Identity: KYC/AML verification is mandatory; until the seller is verified, payouts are frozen. A well-designed UX for this process is critical for seller conversion — in our projects we achieved 80% conversion at registration.

What commission model suits your marketplace?

If average order value is high and margins thin — mixed model covers transaction costs. For B2B with volume discounts — tiered works best. Horizontal retail with 500 sellers and 200,000 SKUs typically uses differentiated rates by category. The wrong model can cost 3–5% of GMV, which directly hits your bottom line.

Why Multitenancy Architecture Is Critical for Data Isolation

The first step is choosing a multitenancy architecture. In shared-schema mode, all sellers are in the same tables with vendor_id. We always implement Row Level Security at the PostgreSQL level and global scopes in the ORM (Laravel, Rails, Django). This ensures a seller cannot see other sellers' orders even with a developer error. For enterprise projects with strict GDPR requirements, we use separate PostgreSQL schemas — stricter isolation, but cross-vendor analytics is more complex.

How to Handle Inventory Without Race Conditions

Two buyers simultaneously add the last item to their cart. Who gets it? Use optimistic locking when creating the order:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Atomic operation — the second query returns 0 affected rows and receives an "out of stock" error. Typical schema for high-traffic marketplaces. Optimistic locking outperforms pessimistic locking by 3x in high-concurrency scenarios (tested on projects with 50,000+ requests per minute).

Comparison of Catalog Approaches

For a niche B2B marketplace, we often choose per-vendor — faster launch. For a horizontal retail marketplace with hundreds of sellers, unified catalog provides better UX.

Moderation Pipeline: Automated and Manual Verification

A marketplace is responsible for seller content. Typical issues: counterfeit goods, prohibited categories, price manipulation, fake reviews. We build a three-tier pipeline:

1. Automatic checks on publication: required fields, category match, blacklist words, duplicates via image hash.
2. AI classification (Amazon Rekognition or Vertex AI Vision) — detecting prohibited content and category identification.
3. Manual review queue for flagged items.

State machine: draft → pending_review → active / rejected → suspended. Each transition is an event with reason and moderator. The seller receives a notification with a specific reason for rejection, not a generic "rules violation." Review verification is mandatory — only after confirmed purchase. Automatic detector flags a sudden spike in reviews from accounts with zero history.

Search and Recommendations

Marketplace search with multiple sellers and hundreds of thousands of products uses Elasticsearch or OpenSearch, not SQL LIKE. Vector search for semantics, faceted filtering via aggregations. Personalized feed based on collaborative filtering. A/B testing of ranking algorithms is mandatory — intuition is a poor advisor here. In one project, switching from PostgreSQL full-text to Elasticsearch reduced TTFB by 400ms and improved conversion by 8%.

Marketplace Development Process

Marketplace development is iterative. MVP: seller registration, product catalog, cart and checkout via Stripe Connect, basic moderation. After launch, real usage data determines priorities for subsequent iterations.

Typical order:

• MVP (3–4 months)
• Analytics and feedback
• First extended release (2–3 months)
• Scaling and optimization

Timeline and Budget

• Marketplace MVP (catalog, checkout, basic seller profiles): 3–5 months.
• Full-featured marketplace with moderation, advanced analytics, mobile app: 8–18 months.
• Adding marketplace functionality to an existing e-commerce: 2–5 months.

Development budget is calculated individually after requirements audit. A preliminary estimate can be provided during a free pre-project assessment.

What's Included

• Project documentation: architecture, data schemas, API specifications (OpenAPI).
• Access to repository, CI/CD, deployment documentation.
• Training for the client's team on platform operation.
• Technical support for the first month after launch.

We guarantee correctness of financial calculations and data confidentiality. Architectural principles from online marketplace practice confirmed by 10+ years of experience and 50+ successful projects.

Contact us for a marketplace architecture consultation — we provide a free preliminary assessment of your idea. Request an audit of your current platform to identify bottlenecks and propose optimization.