The WB API call map

This map shows which WB API methods to call, and in what order, for each core seller workflow. It stays at the level of method names and sequence — parameters, request bodies, response schemas, and limits live in the documentation, which you reach for when you need the details of any one call.

Jump to a workflow from the contents; each section lists the calls in the order you make them, and flags the mistake that most often trips people up.

---

Before you start

You need a seller account and a token. The API is a programmatic view of your Wildberries seller account, so the account comes first — if your company is based outside Russia and you don't have one yet, start with Become a WB seller from abroad. Everything else runs on a token created in that account.

A token carries a fixed set of data categories, and each category unlocks one of the areas below — so a token that works for orders can return 403 on promotion until you re-create it with that category added. Match the token's categories to the areas you plan to call: see Authorization.

There's no single base URL. The API is split across several hosts — one per area (content, prices, orders, promotion, finances, and so on), all under the wildberries.cn domain on this market. Each method's page in the documentation names the host to call.

Two calls prove a token before you build on it:

• GET /ping — call it on the host of the area you're about to use. It confirms the host is reachable, the token is valid, and the token's category matches that service. See Connection check.
• GET /api/v1/seller-info — confirms the token resolves to the account you expect.

A 401 means the token is missing or expired; a 403 means the token was accepted but can't be used for this method: most often it lacks the category for that area, or the method needs a different token type — fix the token, don't retry the call.

Never called the WB API before? Your first request in 15 minutes walks you through these two calls end to end.

---

The overall order

---

How writes behave

Most bulk writes in the WB API — new cards, price uploads, media — are asynchronous: a 200 means the task was accepted, not that the change is live. Each such area has a companion read or status method (named in its section) that reports what actually applied. Treat "accepted" and "applied" as two different states and confirm the second before moving on. The sections below don't repeat this at every step — assume it wherever a write is followed by a status call.

---

Product cards

1. See what you already have — POST /content/v2/get/cards/list. It returns one page; for a catalog above ~100 cards, keep calling it with the cursor (updatedAt + nmID) from the previous response until a page comes back short.
2. Prepare a category — a card is always created inside a subcategory with its own set of characteristics: parent categories GET /content/v2/object/parent/all → subcategories GET /content/v2/object/all → characteristics GET /content/v2/object/charcs/{subjectId}.
3. Create — POST /content/v2/cards/upload.
4. Confirm — created cards appear in POST /content/v2/get/cards/list; anything rejected is listed with a reason in POST /content/v2/cards/error/list.
5. Add media — files with POST /content/v3/media/file, or by link with POST /content/v3/media/save.

Editing existing cards is the same rhythm with POST /content/v2/cards/update. See Listings, Categories, subcategories, and characteristics, and Media files.

---

Prices and discounts

1. Read current prices — GET /api/v2/list/goods/filter.
2. Submit an update — POST /api/v2/upload/task.
3. Check the result — processed: GET /api/v2/history/tasks; still queued: GET /api/v2/buffer/tasks; per-item rejections: GET /api/v2/history/goods/task.

The trap: a discount that drops the price below the quarantine threshold sends the item to price quarantine — the upload still returns success, the item keeps selling at the old price, and the only signal is an item-level error in the upload details (GET /api/v2/history/goods/task). List what's held with GET /api/v2/quarantine/goods after any steep cut. (Size-level prices are exempt — they don't quarantine.) See Prices and discounts.

---

Orders (FBS)

The loop when you ship from your own warehouse: poll → assemble → hand over.

1. Poll new orders — GET /api/v3/orders/new on a schedule. There's no push; it returns what's new at the moment of the request.
2. Group into a supply — create it with POST /api/v3/supplies, add assembly orders with PATCH /api/marketplace/v3/supplies/{supplyId}/orders.
3. Print stickers — POST /api/v3/orders/stickers.
4. Hand over — PATCH /api/v3/supplies/{supplyId}/deliver.
5. Track status — POST /api/v3/orders/status, keyed by order ID; the order lists themselves don't carry a lifecycle status field.

Keep availability current alongside: warehouses GET /api/v3/warehouses, stock PUT /api/v3/stocks/{warehouseId}.

The trap: hand the supply over explicitly with deliver. If you don't, scanning its QR code or accepting its first item at the pickup point closes it for you — and any items still unscanned after the waiting period have to be re-shipped: find them with GET /api/v3/supplies/orders/reshipment and move them into another active supply.

See FBS assembly orders and FBS supplies.

---

Sales statistics

The operational view of what's selling — updated every 30 minutes, ahead of the settled financial report:

• Orders — GET /api/v1/supplier/orders.
• Sales and returns — GET /api/v1/supplier/sales.

Both page by time: without flag (or with flag=0) a single response is capped at 80,000 rows, so feed the last row's lastChangeDate into the next request's dateFrom until the response comes back empty ([]). These figures are operational — the reconciled numbers for accounting come from the financial report below. See Main reports.

---

Promotion

1. List campaigns — counts GET /adv/v1/promotion/count, details GET /api/advert/v2/adverts.
2. Create — POST /adv/v2/seacat/save-ad.
3. Manage — start GET /adv/v0/start, pause GET /adv/v0/pause, change bids PATCH /api/advert/v1/bids.
4. Fund — top up a campaign's budget with POST /adv/v1/budget/deposit.
5. Measure — GET /adv/v3/fullstats.

The trap: budget and balance are two different things. You put money on a campaign through its budget (POST /adv/v1/budget/deposit); GET /adv/v1/balance is an account-level read — your promotion account, its auto-settled balance, and bonuses — not where campaign funding goes.

To join marketplace promotions: list them with GET /api/v1/calendar/promotions, add eligible items with POST /api/v1/calendar/promotions/upload. See Campaigns and Finances.

---

Reviews, questions, chats, and returns

One poller drives all of it — GET /api/v1/new-feedbacks-questions tells you what's waiting across reviews and questions. From there:

• Reviews — list GET /api/v1/feedbacks, reply POST /api/v1/feedbacks/answer.
• Questions — list GET /api/v1/questions, reply or dismiss PATCH /api/v1/questions.
• Buyer chats — chat list GET /api/v1/seller/chats, new events GET /api/v1/seller/events, send a message POST /api/v1/seller/message.
• Return requests — list GET /api/v1/claims, answer PATCH /api/v1/claim.

The trap: a reply can be edited only once, within 60 days of sending it — each item's editable flag tells you whether that edit is still available. Get the answer right the first time. See Feedbacks and the neighboring sections of the same page.

---

Reading your data

Two areas answer "how is the business doing," on different clocks:

• Finances — the settled money. Balance GET /api/v1/account/balance; the list of sales reports POST /api/finance/v1/sales-reports/list, line-level detail POST /api/finance/v1/sales-reports/detailed. Check token-type requirements in the relevant method documentation. These are reconciled and period-based — the source of truth for accounting. See Balance and Financial reports.
• Search analytics — how buyers find you. The main report POST /api/v2/search-report/report; queries for a specific item POST /api/v2/search-report/product/search-texts — these methods need a Jam subscription. See Search queries for your items.

---

Limits and errors

Every method documents its own rate limit. A 429 means you've hit it — the X-Ratelimit-Retry header says how many seconds to wait, so back off on that value instead of hammering. One sharp edge in the Marketplace category (orders and supplies): a 4XX response counts as 10 requests against your limit, so a loop that keeps erroring drains the budget ten times faster than a healthy one. Fix the request rather than retrying it blindly.

Error responses use standard HTTP status codes; each method's documentation lists the ones it returns.

---

When a method you use is deprecated

Deprecations are announced in Release Notes ahead of removal. When an entry names a method you call: treat the removal date as your deadline, find the replacement — the entry usually names it — and read its documentation before migrating, since parameters and response fields often differ. Confirm the switch with a real request, ahead of the date. A new field in a response, by contrast, is routine: a parser that ignores unknown fields rides through it.

---

New to the WB API? The business-level picture — what the API automates and how access works — is in WB API: an overview for your business.