Your first request in 15 minutes

The fastest path to a working, authenticated call to the WB API — a token, one header, one GET.

108

Publication date: 09.07.2026

content

In the next 15 minutes you'll go from nothing to a real WB API response. Four steps: get a token, add it to one header, check the connection, then pull real data. No prior experience needed — just access to your Wildberries seller account and a terminal.

Every request to the WB API is authenticated with a token. You send that token in the Authorization header, the API checks it, and answers. That's the whole model — once your first call works, every other method works the same way.

Step 1. Get a token

A token is the key that authenticates each request — create one in your Wildberries seller account.

No seller account yet? If your company is based outside Russia, Become a WB seller from abroad covers how to register first.

  1. Sign in to your Wildberries seller account and open the API Integrations section of your profile.
  2. Create a token. For a first request, any category works — you can create a token with the exact ones you need later. If you don't see the API Integrations section, ask the account owner.
  3. Copy the token in full and save it right away. It's shown only once and can't be recovered — if you lose it, you create a new one.

A token is a long string. Copy it whole, with no extra spaces or line breaks — a truncated token is the most common reason a first request fails.

Which capabilities you get depend on your token

The mechanics below — the host, the header, the request — are the same for everyone. Which data categories a token can access depends on the ones it was granted, so if a specific method isn't available to you, that's expected. A first /ping and seller-info call work with a token of any category.


Step 2. Add the Authorization header

You authenticate by sending the token in the Authorization header — nothing else is required for a simple GET.

There's no separate login step and no session. Each request carries the token on its own. In curl, that's the -H "Authorization: YOUR_TOKEN" flag; in any HTTP client, it's a header named Authorization whose value is the token.

Keep the token out of logs, screenshots, and shared code. Treat it like a password.


Step 3. Check the connection with a GET

Start with the simplest possible call — /ping confirms the token works and the API is reachable. It returns no store data and changes nothing.

Replace YOUR_TOKEN with your token and run this in a terminal (on Windows, use PowerShell 7 or Git Bash — in older PowerShell, curl is an alias for a different command):

curl -X GET "https://common-api.wildberries.cn/ping" \
  -H "Authorization: YOUR_TOKEN"

A successful response looks like this:

{
  "Status": "OK",
  "TS": "2026-07-01T10:00:00Z"
}

"Status": "OK" is your first success — the connection works and the token is accepted.


Step 4. Get real data and read the response

Now a call that returns actual data — /api/v1/seller-info gives your store's name and identifiers. It also works with a token of any category and changes nothing.

curl -X GET "https://common-api.wildberries.cn/api/v1/seller-info" \
  -H "Authorization: YOUR_TOKEN"

The response is JSON with your store's data:

{
  "name": "Example LLC",
  "sid": "a1b2c3d4-0000-0000-0000-000000000000",
  "tin": "1234567890",
  "tradeMark": "Example"
}

Every WB API response has the same three parts:

  • HTTP status code — the result of the request. 200 means success and the data is in the body. 4XX means something's wrong with the request; 5XX means a problem on the server side.
  • Response body — the data itself, as JSON on success, or an error description.
  • Response headers — service information about the request.

That's the full cycle: an endpoint, an Authorization header, and the JSON that comes back. Most other methods in the documentation follow the same shape — for requests that send a JSON body, you add a Content-Type: application/json header as well. A few methods take other formats or extra headers; their descriptions list them.


If you get a 401 instead

A 401 means the API didn't accept your token — the request never reached the data.

The usual causes, in order of likelihood:

  • The token was copied incompletely — a missing character at the start or end. Copy it again, whole.
  • There's a stray space or line break in the header value.
  • The token has expired or was deleted — create a new one in your seller account.

Fix the header and rerun the same /ping call. Once /ping returns "Status": "OK", seller-info will work too.


What you can do next

Plan the integration

See which methods to call, and in what order, for every core seller workflow.

Go deeper on tokens

See how authorization works end to end — token types, categories, and lifetime.