WB API Token System Update
New token types for enhanced security and convenience
Publication date: 20.10.2025
What Has Changed
As of today, an updated token system is available in the WB API — we've revamped authorization to make integrations more secure, transparent, and convenient for both sellers and developers.
Key Points at a Glance
- 4 types of tokens are now available instead of one
- All existing tokens continue to work as before (180 days)
- No urgent action required
New Token Types
Personal Token
Purpose: A special token for self-developed or purchased ready-made corporate solutions in on-premise edition (including 1C boxed solutions), deployed on the seller's infrastructure.
Key Features:
- Extended access to data categories (initially, the list of categories is the same as for the base token, but in the future, new categories will be added that will only be available with personal tokens. For example, user management — we'll announce this separately)
- Works only with boxed (local) solutions on owned or leased infrastructure
- Will not work with cloud services
- Requires accepting a responsibility warning upon creation
- Transfer to third parties is prohibited
When to Use:
- Company's self-developed software
- Purchased ready-made ERP/CRM systems in boxed edition (also known as local or on-premise solutions), including 1C, hosted on company servers or employee computers
Example Use Case:
A seller uses 1C on the company server for warehouse and product management. They need integration for automatic product uploads to Wildberries and inventory synchronization. A Personal token is created with read and write access to "Content" and "Marketplace" categories.
Read in a separate article how to create, update, or delete a WB API token
Service Token
Purpose: A specialized token for connecting a specific cloud service from the official Business Solutions Catalog on Wildberries.
Key Features:
- Tied to a specific service and works only with it
- Simplified creation: the seller selects a service from the list, all settings are filled in automatically. The seller only needs to confirm creation. If necessary, settings can be adjusted, but in this case, not all service features may be available
When to Use:
- Connecting any cloud service from the Solutions Catalog
Note: If you see when issuing a service token that the service is available in two versions — cloud and local (boxed) — clarify if necessary which version you need. If you have the cloud version, continue with the service token issuance; if local, proceed to create a personal token.
Example Use Case:
A seller wants to connect an analytics service from the Solutions Catalog. They select the required service in the token creation interface, the system automatically prefills the necessary categories ("Analytics", "Statistics") and access level ("Read Only"). The seller only needs to confirm creation and provide the token to the service.
Base Token
Purpose: An auxiliary token for cases where Personal or Service tokens are not suitable.
Key Features:
- Access to a limited list of data categories (for now, the list of categories is the same as for personal tokens, but in the future, data categories will appear that will only be available with personal tokens — we'll announce this separately)
- The seller independently selects the necessary categories and access rights
When to Use:
- Verifying integration with real data before launch
- In all other cases when other token types are not suitable
Example Use Case:
A developer has finished creating an integration in the sandbox and wants to test it with real store data before the final launch. A Base token is created with the minimum necessary categories for pilot testing.
Test Token
Purpose: A special token for safe testing and debugging of integrations in an isolated environment (WB API sandbox).
Key Features:
- Works only with the sandbox, has no access to real store data
- Automatic access to all data categories available in the sandbox
- Always works in read and write mode
- Does not require selecting data categories upon creation
When to Use:
- Developing and debugging custom integrations
- Exploring API capabilities
- Testing new features before implementation
- Experimenting with API methods
Example Use Case:
A developer is creating a new integration for inventory management and needs to test API method behavior without risking real product data. They create a Test token and work in the sandbox environment until full confidence in the solution's correctness.
Understanding the Token System
What is a Token?
A token is a unique key that provides access to a seller's data through the API. Think of it as an electronic key that grants access to specific data categories and operations.
Why Were Changes Made?
The previous system was simple but not flexible enough. One token with full access to all data created security and management challenges. The new system lets you:
- Separate access rights for different integration types
- Control which data each token can access
- Easily revoke access for a specific service without affecting others
- Better protect seller data from unauthorized access
How to Choose the Right Token?
Use this simple decision tree:
- Do you need to work in the sandbox? → Test Token
- Are you connecting a cloud service from the Catalog? → Service Token
- Do you have your own software or boxed solution (1C and similar) on your infrastructure? → Personal Token
- None of the above? → Base Token
Migration to the New System
How Will the Transition Work?
The transition to the new token system will happen in two stages:
Stage 1 (available now)
- All existing tokens continue to work exactly as before
- New token types are available alongside the old ones
- No changes to the API itself — all methods and responses remain the same
Stage 2 (planned for 2025 Q2)
- Old tokens will be automatically converted to new types based on their usage:
- If used in a service from the Catalog → Service Token
- If not used or used with on-premise solutions → Personal Token
- All functionality will be preserved, only the token type will change
- You will receive advance notification of the conversion
Recommendations for Sellers
- If you're just starting to work with API — immediately use the new token types according to the recommendations above
- If you already have integrations on old tokens:
- You can continue using them for now
- We recommend starting to explore the new token types and planning the migration
- If necessary, start creating tokens of new types for new integrations
Recommendations for Developers
If you're developing a service for the Catalog:
- Read the documentation on how to connect via API using a token
- Prepare your service to accept Service Tokens
- Update your instructions for sellers, considering the changed process of issuing and transferring tokens
- If the service is a boxed solution — provide clear instructions on what token type to use
Frequently Asked Questions
Which token type should I choose for quick testing?
- For testing in sandbox: simply create a Test Token
- For testing with real data: create a Base Token or Personal Token depending on your scenario
Can I have multiple tokens?
Yes, you can create any number of tokens of any type. Each token can have different access rights and be used for different purposes.
What happens to my integrations after 180 days?
Old tokens will expire as usual. Just create a new token of the appropriate type according to the updated rules before expiration.
I'm a service developer. Can I continue accepting old tokens?
Yes, old tokens will work until expiration. But we recommend:
- Updating documentation to reference Service Tokens
- Adding a check to not accept Personal or Service tokens from other services in the Catalog
- Preparing users for the transition to the new system
Can a Personal Token be used for a cloud service?
No. A Personal Token is technically blocked for use with cloud services. This is done for security, as the Personal Token provides extended data access that should not leave the seller's controlled infrastructure.
I have 1C. Which token should I choose?
Depends on the 1C version:
- Local/boxed version on your server or computer → Personal Token
- Cloud version from a provider in the Catalog (e.g., 1C:Fresh) → Service Token
- Cloud version on 1C servers (not from the Catalog) → Base Token