In this article, we have described a new approach to authorizing API requests for third-party services from the Business Solutions Catalog.

OAuth 2.0 technology is the optimal way to authorize service API requests. However, we see that not all developers from the solutions catalog are ready to support this technology at this time. Therefore, we are planning to implement simplified authorization for API requests from catalog services.

Changing the authorization technology is important for enhancing security. In the future, this will become the foundation for new capabilities for services from the Solutions Catalog: for example, we will be able to provide services with separate rate limits independent of sellers.

---

How API Request Authorization Works Now

For a service to gain access to seller data, currently one of two conditions is sufficient:

1. Receive an API token from the seller.
2. Connect to the seller's profile via OAuth 2.0, if the service supports connection through this technology.

---

What Is Changing

For all services from the Business Solutions Catalog, a special service token-secret or Service Secret will be generated.

You will need to pass the service secret in all requests to seller data through the WB API, in the X-Client-Secret header. This will be used to identify which specific service is accessing seller data on their behalf.

The service secret lifetime is 180 days. A new service secret will be generated 30 days before expiration. Two secrets will be valid simultaneously until the old one expires.

Sellers will also be able to create four types of tokens instead of one:

---

New API Workflow

All services from the Business Solutions Catalog must pass when sending API requests:

• the Service Token provided to them by the seller
• the Service Secret, encoded using the open JWT standard.

Tokens that services received from sellers before the launch of the new authorization scheme will continue to work as Base Tokens until the end of their validity period. All requests to WB API using base tokens must also be signed with a service secret.

New services just added to the catalog can temporarily use base tokens until they expire. Requests with them must be signed with a service secret.

It is prohibited to use Personal and Service Tokens from other services in the Solutions Catalog to connect new sellers. Requests with such tokens will not pass through WB API.

We do not recommend accepting Test Tokens for connecting sellers, as they do not provide access to real data. Using a test token to evaluate the performance of a finished third-party service can negatively impact the seller's experience.

• If your service is a ready-made corporate solution as an on-premise version deployed on seller's servers, such an integration is considered the seller's own integration. In this case, you may not sign requests to WB API with a service secret. Use the seller's Personal Token for connection.
• If a service from the Solutions Catalog is distributed in both cloud and on-premise versions, the service secret should only be passed in requests to the cloud version of the WB API product. Use a Service Token to connect the cloud version of the product.

---

How to Verify a Token Received from a Seller

Tokens issued by sellers are encoded using the open JWT standard.

Decode the token in a convenient way. Determine the token type by the list of fields from the token's payload:

Compare the asid of the seller's Service Token with your asid:

• If the values match, the token was issued for your service.
• If the values do not match, the token was not issued for your service and cannot be accepted. Inform the user about this.

---

How to Sign API Requests with a Service Secret

In each request on behalf of the seller, in addition to the Authorization header with the seller's token, you must add the X-Client-Secret header with the value of the service secret issued to a specific service from the Catalog.

Example request to WB API with service secret:

curl \
   -H "Authorization: Bearer ${ACCESS_TOKEN}" \
   -H "X-Client-Secret: ${SECRET_TOKEN}" \
   https://marketplace-api.wildberries.ru/api/v3/orders/new

Responses

---

Implementation Stages

Stage 1

1. We will generate and provide individual Service Secrets to all services. You can reissue your secret by writing to business-solutions@rwb.ru.
2. On their side, the service must:
   • Implement an additional service secret in the signature of all API requests.
   • Launch the process of determining token type passed by the seller.
   • Not accept Personal or Service Tokens issued for other services from the Catalog.

Stage 2

1. Sellers on the Portal will be able to issue Personal, Service, and Base Tokens.
2. Services will be provided with links that can be added to instructions for connecting services to the seller's profile on WB Partners. Via the link, the seller will go to authorization on WB Partners and then to creating a Service Token for a specific cloud service. All mandatory token settings for working with the service will be automatically filled in advance. The seller will only need to confirm token creation and provide it to the service for integration connection.
3. The service must not accept Personal or Service Tokens from other services in the Solutions Catalog for connecting cloud versions of products.
4. The service must update user instructions for sellers, considering the changed process of creating and transferring tokens. If the service is distributed in cloud and on-premise versions, the instructions should specify which token type the seller needs to use to connect their product version.

---

Contacts and Support

For all questions, contact:

• Telegram chats for each service from the Catalog.
• email at business-solutions@rwb.ru.