Catalog, prices and stock move from the seller account into your system on a schedule, not by hand. The interface reads your own database, never a third party API, so a pause on the platform side does not take the pages down. Most of this work ran against Wildberries and Ozon, two major e-commerce marketplaces, and the same shape ports to other seller APIs.
Where marketplace API integration breaks
The docs describe endpoints. They do not describe how the platform behaves under load. These are the four places where a seller account integration trips up most often.
The rate limit belongs to the account
The request budget is counted for the whole seller account, not for your application. Every service the owner has already connected spends it, so a new sync has to fit inside what is left.
The pause has to be read
The platform announces the wait in a header of its own, and the familiar standard header may be absent from the response. Guess the delay instead of reading it and the retries burn the limit in circles.
Heavy reports get truncated
A large export returns the first rows up to a cap rather than everything. So statistics are pulled one day at a time and the history is kept locally, otherwise a long period goes missing in silence.
Filtering on the wrong date
Selecting by the modification date instead of the order date quietly breaks catalog ordering and report windows. Nothing crashes. The numbers simply stop adding up.
What the work includes
The scope is shaped per project, but the skeleton of e-commerce marketplace automation stays the same: your database is the source of truth, and the exchange with the platform runs on a schedule.
Catalog sync
Products, attributes, photos and stock arrive from the seller account on a schedule. The storefront and the reports read your database, while the platform API stays a source of updates.
Colorways merged into models
The platform issues one card per color. They are merged into a model through a separate field, otherwise the catalog falls apart into hundreds of near identical entries.
Catalog and price sync
The site price is derived from the seller price by a rule. The marketplace storefront shows less because of a loyalty discount the API does not expose, so the rule carries a base you can see and edit.
Field locks
Manual edits are protected by a lock on the specific field. The nightly run walks around locked fields and never overwrites what a person changed on purpose.
Sales statistics
Orders, sales and ad spend are pulled one day at a time and stacked into your own history. Reports are then built from that history, without hitting the platform API on every screen.
Schedule and visibility
The exchange runs as scheduled jobs with a queue, retries and a log. You can see when the last successful sync finished and exactly what failed to arrive.
How the work runs
- Account and data review. I look at which endpoints are already in use, what else eats the rate limit, and which fields you need on the other end. The stage ends with a written scope and a price.
- Your schema and the first import. First a schema for product, price and stock, then a full catalog import. Data is checked against a live seller account, not against samples from the docs.
- Schedule and rules. Frequency, priorities and pricing rules get set up. Field locks appear here too, so manual work is not wiped by the nightly run.
- Handover. Server, access and code are yours. A README per exchange: which endpoints are called, how the pause is computed, what to do when the platform changes its response format.
What it looks like in practice
Each system has a detailed teardown and a clickable demo on fictional data. Client names are withheld, the numbers are real.
Common questions
What does a marketplace API integration cost
It depends on how many endpoints have to be called and on what the system does with the data afterwards. The seller account review is a short separate stage and ends with a written scope and a price. After it you can walk away and take that document to any contractor.
What happens to the site when the marketplace API is down
The pages stay up. The interface reads your own database, while the exchange with the marketplace runs as a scheduled background job. When the platform goes quiet, visitors see the last data that arrived successfully and the job retries on the next pass.
Why does the site price differ from the price shown on the marketplace
The price on the marketplace storefront is usually below the seller price by a loyalty discount that the API does not expose. So the site price is derived from the seller price by a rule, and that rule has a base you can edit. The storefront stays predictable instead of drifting with someone else's promotions.
We already run other tools on the same seller account, is there enough rate limit
The request budget is counted for the whole seller account, not per application. Every tool the owner has connected spends the same budget. That is why the exchange runs on a schedule, heavy exports are spread across the day, and the wait time is read from the response header instead of being guessed.
Will manual edits survive the nightly sync
Yes, that is what field locks are for. A locked field is skipped by the nightly run while the rest keep updating from the seller account. Without locks any manual edit lives only until the next exchange.
Which marketplaces do you work with
Most of the work went through Wildberries and Ozon, two major e-commerce marketplaces. The mechanics repeat elsewhere: authentication, an account-wide rate limit, day-by-day reports, and platform specific card and price logic. Your own data schema and the sync schedule move to another API without rewriting the system.
If this sounds familiar, write a couple of lines about what still moves by hand today: LinkedIn or Telegram. What comes back is questions about the work, not a pitch deck.