# Система авторизации WB API — токены, секреты и права доступа
- Collection: developer.wildberries.ru
Documentation
Release Notes
Swagger
Sandbox
API Status
Community
Knowledge Base
More
Documentation
Release Notes
Swagger
Sandbox
API Status
Community
Knowledge Base
Sign In
Where to start
What is WB API
Developer portal
Connecting to the API
Authorization and security
WB API authorization system
Seller data security when working with WB API
Decoding and verifying WB API tokens
Working with tokens for partner services
WB API authorization errors and how to fix them
Testing and the sandbox
Working with the API
Monitoring and updates
The WB API platform for services
Training and support
Guides
Case studies
Tool integrations
Cookbook
Home
/
Authorization and security
/
WB API authorization system
WB API authorization system
Token types, the service secret, and the access-separation principle
Publication date: 27.09.2026
How authorization works
To work with WB API, you first need to be authorized — to confirm that you have the right to access a store's data. Authorization is done with a token that you pass in the header of every request:
Authorization: your_token
The WB API authorization system is built on the access-separation principle. Access is controlled at three levels:
Token type defines the use case: your own programs, cloud services, or testing.
Data categories restrict access to specific parts of the API: content, orders, analytics, and others.
Access level sets the operating mode: read-only, or read and write.
This structure minimizes risk: even if a token leaks, an attacker gains access only to a limited set of data within the chosen categories.
Token types
WB API uses four token types. Each is designed for a specific use case:
Starting March 30, 2026, reduced request limits apply to Base tokens. The full list of values by method is in the article “WB API rate limits”.
For more on each type, including a comparison and recommendations on which to choose, see the article “Ways to connect to WB API: token and OAuth 2.0”. If you're not sure which type fits your needs, see the article “Cloud service or local solution: how to tell them apart and which token to choose”.
Which token fits your scenario
The right token depends on who you are and what you do:
The complete guide to choosing a token and a connection method for SaaS developers is in the article “Authorization for services”.
Common rules
All WB API tokens follow the same rules: they are valid for 180 days, shown only once at creation, and created and deleted only by the account owner. You can create up to 20 active tokens per store.
Step-by-step instructions for creating, refreshing, and deleting tokens are in the article “How to create, refresh, or delete a WB API token”. For which data categories to select at creation, see the article “WB API data categories: how to choose the right ones for your integration”.
How request authorization works
When your program sends a request to WB API, the system runs several checks:
1. Token presence and integrity. The API checks that the Authorization header contains the full token, without the Bearer prefix, and that the token is not corrupted. If the token is missing, truncated, or malformed, it returns a 401 error.
2. Validity period. The API checks whether 180 days have passed since the token was created. If the token has expired, it returns a 401 error with the description token expired.
3. Token and account status. The API checks that the token has not been revoked and that the seller's account is active. If the account is blocked, it returns a 401 error. After the account owner changes, the tokens created before the change go into a 120-hour quarantine: requests with them to the main data categories fail with errors. When the quarantine ends, these tokens are revoked automatically.
4. Data category. The API checks that the token has access to the category the called method belongs to. For example, working with orders requires the “Marketplace” category. If the category doesn't match, it returns a 403 error.
5. Access level. For methods that modify data (POST, PUT, DELETE), the API checks that the token was created with the “Read and Write” permission. “Read-only” tokens cannot perform modifying operations — a 403 error.
6. Token type. Personal tokens don't work through cloud services; Service tokens work only with the service they were created for. A type mismatch returns a 403 error.
If all checks pass, the API processes the request and returns the result.
A detailed breakdown of 401 and 403 errors, with solutions for every case, is in the article “WB API authorization errors and how to fix them”.
Two ways to connect
Besides creating a token manually, cloud services from the Solutions Catalog can connect via OAuth 2.0 — the seller confirms access in the interface, and the token is generated and refreshed automatically. For a comparison of both methods, see the article “Ways to connect to WB API: token and OAuth 2.0”.
Service secret for partner services
Services from the Solutions Catalog must sign their requests with a special service secret — a unique service identifier that proves the service's authenticity. The secret is passed in the X-Client-Secret header in addition to the seller's token:
Authorization: seller_token
X-Client-Secret: service_secret
The secret is available to a registered service — even before publication in the Solutions Catalog. You can issue a new secret or delete an existing one in the Company Profile on the portal. The secret is valid for 180 days. Once a new one is issued, the old one's lifetime is shortened to 30 days, or left as is if less than that remained — that is the window for the swap.
For more on working with sellers' tokens, checking the token type, and handling errors, see the article “Working with tokens for partner services”.
Checking and diagnosing a token
If your integration returns errors, the first step is to check the token. WB API provides a decoding tool that shows the token's type, validity period, available categories, and status.
For more, see the article “Decoding and verifying WB API tokens”.
Where to get help
Authorization problems → check your token in the decoding tool, then read the article “WB API authorization errors and how to fix them”
How to protect your data → recommendations in the article “Seller data security when working with WB API”
API questions → create a request in Wildberries seller support, category “API Integrations”
Service secret questions → business-solutions@rwb.ru
Russia
User Agreement of the WB API Service
WB API Platform Access Agreement
WB API Price List for Third-Party Services
Personal Data Processing Policy
Cookie Policy
Cookie Settings
FAQ. Frequently Asked Questions