Publication date: 09.07.2026
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.
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.
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.
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.
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.
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.
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:
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.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.
A 401 means the API didn't accept your token — the request never reached the data.
The usual causes, in order of likelihood:
Fix the header and rerun the same /ping call. Once /ping returns "Status": "OK", seller-info will work too.
See which methods to call, and in what order, for every core seller workflow.
See how authorization works end to end — token types, categories, and lifetime.