Online Store Integration with Ozon Seller API

Online Store Integration with Ozon Seller API

Imagine you manually update 5000 products on Ozon through the personal account. One employee spends a whole day on this, and tomorrow the stocks drift apart again. Discrepancies lead to order cancellations and fines from the marketplace. According to statistics, up to 15% of orders are cancelled precisely due to outdated stock data. This is a familiar situation for many sellers. We solve it via Ozon Seller API — a single channel for bidirectional synchronization that eliminates the human factor. Our engineers hold Ozon certifications and have over five years of experience in e-commerce integrations. During this time, we have implemented projects with catalogs ranging from 5000 products, where automation reduced manual labor by 120 hours per month, saving the client around 600,000 rubles per year. Contact us for a free audit of your current setup.

What tasks does integration with Ozon solve?

Manual catalog management on the marketplace is a source of problems: outdated prices, duplicated products, stock errors. Automation via Seller API addresses three key tasks:

• Product synchronization: import and export of nomenclature with attributes (name, brand, description, characteristics). Asynchronous import requires proper handling of task_id.
• Price and stock synchronization: real-time updates from your CRM or ERP. We account for rate limits and batching (up to 500 SKUs per request for stocks).
• Order management: receiving new orders, updating statuses (awaiting_packaging → awaiting_deliver → delivered). Integration supports FBS and FBO.

According to the official Ozon documentation, asynchronous tasks require polling of task_id and proper error handling.

Why is automatic synchronization more profitable than manual management?

Manually updating 1000 products takes about 4 hours, while automatic update takes 2 minutes — a 120-fold difference. Additionally, human errors are eliminated: forgetting to update a price means lost profit. Automatic synchronization ensures that data on Ozon is always up-to-date, and orders are not stuck due to outdated stock levels. Moreover, automation allows business scaling without hiring additional staff.

How do we implement synchronization?

We use the Repository pattern to abstract API calls and a task queue for asynchronous operations. On errors (timeout, 429 Too Many Requests), we apply exponential backoff with retries. Laravel 11 with Redis and Horizon allows managing queues without data loss.

Authentication

$headers = [
    'Client-Id' => config('services.ozon.client_id'),
    'Api-Key'   => config('services.ozon.api_key'),
    'Content-Type' => 'application/json',
];

$base = 'https://api-seller.ozon.ru';

Create/Update Products

class OzonProductService
{
    public function upsertProduct(Product $product): void
    {
        $payload = [
            'items' => [[
                'attributes' => [
                    ['id' => 9048,  'complex_id' => 0, 'values' => [['value' => $product->name]]],
                    ['id' => 4191,  'complex_id' => 0, 'values' => [['value' => $product->brand]]],
                    ['id' => 85,    'complex_id' => 0, 'values' => [['value' => $product->description]]],
                ],
                'barcode'           => $product->barcode ?? '',
                'description_category_id' => $this->getCategoryId($product),
                'name'              => $product->name,
                'offer_id'          => $product->sku,
                'price'             => (string) $product->price,
                'images'            => $product->images->pluck('url')->all(),
                'vat'               => '0.2',
            ]]
        ];

        $resp = Http::withHeaders($this->headers)
            ->post("{$this->base}/v3/product/import", $payload);

        $taskId = $resp->json('result.task_id');

        // Creation status is asynchronous — check via task_id
        $this->waitForTask($taskId);
    }

    private function waitForTask(string $taskId): void
    {
        for ($i = 0; $i < 30; $i++) {
            sleep(2);
            $status = Http::withHeaders($this->headers)
                ->post("{$this->base}/v1/product/import/info", ['task_id' => $taskId])
                ->json('result.items.0.status');

            if ($status === 'imported') return;
            if ($status === 'failed')   throw new OzonImportException("Task {$taskId} failed");
        }
        throw new OzonImportException("Task {$taskId} timeout");
    }
}

Update Prices and Stocks

public function updatePrices(array $items): void
{
    // items: [['offer_id' => 'SKU-123', 'price' => '1990', 'old_price' => '2490']]
    Http::withHeaders($this->headers)
        ->post("{$this->base}/v1/product/import/prices", ['prices' => $items]);
}

public function updateStocks(array $items): void
{
    // items: [['offer_id' => 'SKU-123', 'stock' => 15, 'warehouse_id' => 12345]]
    Http::withHeaders($this->headers)
        ->post("{$this->base}/v2/products/stocks", ['stocks' => $items]);
}

Get Orders

public function getNewOrders(): array
{
    $resp = Http::withHeaders($this->headers)
        ->post("{$this->base}/v3/posting/fbs/list", [
            'filter' => [
                'since'   => now()->subHours(24)->toIso8601String(),
                'to'      => now()->toIso8601String(),
                'status'  => 'awaiting_packaging',
            ],
            'limit'  => 50,
        ]);

    return $resp->json('result.postings');
}

Asynchronicity of API

Ozon actively uses asynchronous tasks: product creation, bulk stock updates. It is crucial to properly handle task_id and statuses. We added automatic retry on failure and Telegram notifications for failures.

When is integration indispensable?

If your catalog exceeds 1000 SKUs or you operate under FBS with frequent stock updates, manual synchronization becomes a bottleneck. Stock errors lead to cancellations — each cancelled order can cost up to 500 rubles in fines plus lost loyalty. Automation pays off within the first few months.

Comparison of Ozon FBS and FBO Schemes

The choice of scheme depends on your sales model. We help set up integration for any option.

Our Achievements

We have been working with Ozon integrations for over 5 years, implemented 30+ projects for catalogs from 1000 to 100,000 SKUs. Average time savings after automation — 120 hours per month, and reduction of order cancellations — up to 90%. Get a consultation from an engineer — we will evaluate your catalog and tell you how to automate Ozon within 2 weeks.

Process of Integration

1. Analytics: we study your catalog, API methods, current processes.
2. Design: choose a pattern (synchronous/asynchronous), define field mapping.
3. Implementation: write code using Test-Driven Development for critical parts.
4. Testing: load testing with simulation of peak loads (e.g., Black Friday).
5. Deployment: deploy on your server (Docker, Nginx, PHP 8.3). Train your team to work with the integration.

What is Included in the Work

• Full integration documentation (architecture, endpoints, data schema).
• Setup of monitoring and alerts (API errors, data discrepancies).
• Training of your manager to work with logs and statuses.
• Guarantee of stable operation during the first 30 days after deployment (free support).

Timeline

Basic integration (products + prices + stocks + orders) — from 12 to 18 working days. The timeline can be shortened if an API key is ready and data structure is clear. We will evaluate your project for free — contact us for a consultation.

What typical errors occur during integration and how to avoid them?

There are several pitfalls when integrating with Ozon that we have learned to avoid. First, incorrect category attributes when importing products cause errors. Solution — preliminary request for description_category_id and validation. Second, exceeding rate limits when updating prices causes timeouts. Batching 1000 elements and pausing between requests solves the problem. Third, asynchronicity of stock updates can lead to discrepancies — we use a queue with re-synchronization after each successful update.

FBS Order Statuses

Contact us for a free audit of your current integration.

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.