Testing the WB API with Postman

From Your First Request to Confident Use

2279

Testing WB API with Postman

In this article, we’ll walk through how to use Postman to test and work with the WB API. Step by step, you’ll learn how to configure the tool correctly, import ready-made collections, manage environments, and send requests successfully. We’ll also cover more advanced Postman features — from automated tests and monitoring to CI/CD integration. This guide will help you set up your integration with the WB API and automate routine tasks.

Set Up the Tool and Send Your First Request

In this section, we’ll go from installing Postman to sending your first successful request.

Our first goal is simple and clear — get the current stock levels for your Wildberries warehouse using Postman.

Step 1. Install Postman

First, download and install Postman. It’s easy:

Go to the official Postman website.
Choose the version for your OS (Windows, macOS, Linux).
Download and install the app.

After installation, open Postman. You’ll see a simple, intuitive interface ready to use.

Tip: if you’d rather not install the desktop app, you can use Postman on the web directly in your browser.

Step 2. Configure an Environment

Before sending requests, create a separate environment to manage tokens and other variables easily.

Open the Environments section

Create a new environment (Create Environment) and name it, for example, “WB API”.
Add a new variable apiKey — your authorization token obtained in your Wildberries Seller Account. You can also add baseUrl — with this variable, you won’t need to manually paste the base URL for every request; Postman will do it automatically.

Tip: you can easily switch between production and test accounts by simply changing the active environment.

Step 3. Import the WB API Collection into Postman

The fastest way to start is to import the existing WB API documentation (Swagger file) directly into Postman.

Click Import next to your Workspace name.
Paste the WB API documentation URL https://dev.wildberries.ru/yaml/ru/02-products.yaml into the input field — Postman will fetch the methods and offer to import them as a collection.
After import, you’ll see a WB API request collection ready to use.

Step 4. Set Up Authorization for the Collection

Most WB API requests require token-based authorization. Let’s configure auth once at the collection level:

In Collections, select the created collection and open the Authorization tab.
In the token field, specify the environment variable we created earlier: {{apiKey}}

All requests in the collection will now automatically use your authorization token from the environment.

Step 5. Send Your First Stock Request

You’re ready to send your first request.

Open GET /api/v3/stocks/warehouseId in the collection.
Ensure your requests use {{baseUrl}} where applicable and the Authorization header is set via the collection.
Make sure the “WB API” environment is selected at the top right.

Click Send.

In a second, you should see the server response — a list of products and their current stock levels at the warehouse.

Step 6. Inspect the Result in Postman

Once you get a response, analyze it right in Postman:

The Body tab shows a formatted JSON response.
The Headers tab shows response headers, useful for deeper debugging.
The Test Results tab immediately shows whether any tests you added have passed.

If everything is set up correctly, the status should be 200 OK, and the JSON body will contain your current stock data.

Step 7. Save the Successful Request and Baseline Response

After a successful request, it’s a good idea to save the example:

Click Save and give the request a clear name, e.g., “Get Warehouses List”.
You can also save the received response as a baseline example by clicking Save response next to the response panel.

This way, you can quickly reproduce the request and share it with teammates.

Your First Successful Request Is Done

Congrats! You’ve just sent your first request to the WB API using Postman and received a valid response. You no longer need to check stock levels manually in the Wildberries Seller Account — use this ready request instead; it takes just a few seconds.

In the next section, we’ll go further: advanced Postman features — automated tests, monitoring, and request automation — to make WB API integration even simpler and more convenient.

Advanced Postman Capabilities: Testing & Monitoring WB API

Get the Most Out of the Tool for Effective Work

After you’ve successfully sent your first request to WB API and received current data, it’s time to move on. Postman isn’t just for manual requests — it’s a platform for running scheduled tests, monitoring stability, and even generating documentation.

In this section, we’ll cover advanced Postman features that help automate WB API tasks, reduce manual work, and lower the risk of errors.

Organize Requests with Collections & Folders

Collections in Postman let you structure requests by purpose and functionality. Well-organized collections speed up your work and make it clear for the whole team.

Why it helps:

You can quickly find the request you need.
Teammates can navigate and reuse your requests without lengthy explanations.
It’s easy to track changes and group requests by business process.

Work with Environment Variables

Environment variables let you manage multiple environments (production, test, dev) and switch between them without editing requests.

Useful variables to define:

Variable	Description	Example
`apiKey`	WB API authorization token	`abcdef123456`
`warehouseId`	Your warehouse identifier	`12345`
`base_url`	WB API base URL	`https://marketplace-api.wildberries.ru`

Switching environments changes request parameters in one click — perfect for quick testing and debugging.

Automated Tests & Scripts (Pre-request and Tests)

Postman lets you write simple JavaScript tests that run automatically after each request. This helps catch issues early.

Examples of useful tests:

Check for success (status 200):

pm.test("Successful status (200)", function () {
    pm.response.to.have.status(200);
});

Ensure stock list is not empty:

pm.test("Stock data is returned", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.length).to.be.above(0);
});

Verify response time (e.g., under 1 second):

pm.test("Response time is under 1s", function () {
    pm.expect(pm.response.responseTime).to.be.below(1000);
});

These tests run automatically every time you send a request, ensuring integration quality.

Automation & Bulk Requests with Collection Runner

If you have many similar requests (e.g., bulk price updates for hundreds of products), use Collection Runner.

Create a CSV with the list of products and new prices.
In Postman, open Collection Runner and upload the CSV.
Run the collection — Postman will automatically execute a request for each row, greatly accelerating updates.

This can save hours of manual work.

CI/CD Automation with Newman and GitHub Actions

Newman is the CLI runner for Postman — ideal for automation in CI pipelines. With Newman, you can run all tests from your collections as part of Continuous Integration.

A sample automation scenario:

Store your collections and environments in a GitHub repo.
Create a GitHub Actions workflow to run tests with Newman on every change.
Configure notifications (Slack/Telegram) to see results immediately.

Sample GitHub Actions workflow (YAML):

name: WB API Test
on: [push]

jobs:
  run-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - name: Install Newman
        run: npm install -g newman
      - name: Run Postman Collection
        run: |
          newman run wb-collection.json \
            -e wb-production.env.json \
            --reporters cli,html \
            --reporter-html-export report.html
      - uses: actions/upload-artifact@v4
        with:
          name: postman-report
          path: report.html

Now, each time you update the collection, tests run automatically.

(Here you could add a CI/CD pipeline diagram with Newman and GitHub Actions.)

Monitor API Health with Postman Monitor

Monitoring lets you regularly check the availability and correctness of WB API. Schedule key requests (e.g., every 30 minutes) and get alerts when something breaks.

This helps you react quickly to any issues.

(For convenience, also consider using the API Status page if available.)

Mock Servers: When the API Is Temporarily Unavailable

If WB API is temporarily down or rate-limiting, Postman Mock Servers can help. They simulate real API responses so you can continue development and testing without delays.

Section Summary

Using the features above, you can simplify, automate, and improve the quality of your WB API integration.

Next, we’ll briefly compare Postman with other tools so you can confirm it’s the best choice for most WB API scenarios.

Comparing Postman with Other Popular API Tools

When to Choose Postman — and When an Alternative Is Better

Postman is one of the most popular API tools, but not the only one. In this section, we’ll look at well-known alternatives, compare them with Postman, and help you choose the right tool, especially for WB API work.

Postman vs. cURL (Command Line)

cURL is a command-line utility available on most systems, used to make HTTP requests.

Pros of cURL:

Minimalistic and fast.
Great for automation in scripts and on servers.
Easy to integrate into CI/CD.

Cons of cURL:

No graphical interface or response visualization.
Higher learning curve for beginners.
Less convenient for debugging complex requests.

Choose cURL when:

You need simple scripted requests on a server.
You’re comfortable in the terminal.

Choose Postman when:

You want clarity and convenience for the whole team.
You need to quickly test and debug APIs without typing commands manually.

Postman vs. Insomnia

Insomnia is a graphical tool similar to Postman, popular for its light and simple UI.

Pros of Insomnia:

Clean, minimalist interface.
Supports REST, GraphQL, gRPC.
Open source.

Cons vs. Postman:

More limited automation and monitoring.
Fewer collaboration features.
Weaker scripting and test tooling.

Choose Insomnia when:

You need a lightweight GUI for occasional requests.
Open source and minimalism are priorities.

Choose Postman when:

You want maximum automation.
Team collaboration, CI/CD integration, and monitoring matter.

Postman vs. Thunder Client (VS Code Extension)

Thunder Client is a lightweight API client inside Visual Studio Code.

Pros:

Make requests without leaving VS Code.
Great for quick checks during coding.

Cons vs. Postman:

Limited automation and scripting.
No full-fledged monitoring or collaboration.

Choose Thunder Client when:

You need to test simple requests as you code.
You prefer to stay in your editor.

Choose Postman when:

You need powerful automation, monitoring, and teamwork features.
You rely on flexible environments and variables.

Postman vs. SoapUI & JMeter (Specialized Tools)

SoapUI and JMeter are specialized tools (SOAP testing and load testing).

Pros:

SoapUI is strong for SOAP and complex test scenarios.
JMeter is purpose-built for load testing APIs.

Cons vs. Postman:

Higher learning curve and more complex UI.
Overkill for most simple REST API tasks (like WB API).

Choose SoapUI / JMeter when:

You need heavy load testing (JMeter).
You work with SOAP (SoapUI).

Choose Postman when:

You work with REST APIs, including WB API.
You want a balance of simplicity, automation, and visualization.

When Postman Is the Best Choice

Postman is ideal if you need an “all-in-one” solution: user-friendly UI, automation, testing, monitoring, and collaboration.

If you are:

An entrepreneur or beginner who needs a quick, easy API start;
An experienced developer who values flexible automation and CI/CD;
A team member focused on collaboration and shareability,

then Postman is likely the most effective tool for your WB API use cases.

Next, we’ll review Postman’s limitations so you’re prepared for any situation.

Postman Limitations and How to Overcome Them

What to Consider to Use Postman Effectively

Despite its advantages, Postman — like any tool — has limitations. Here’s what to watch for and how to address it when working with the WB API.

1. No Built-in Load Testing

Postman is great for functional testing and everyday automation, but it’s not designed for heavy load testing (thousands of concurrent requests).

How to handle it:

Use specialized tools for load tests:

Apache JMeter — powerful GUI-based load testing.
k6 — modern, script-friendly load testing.
Gatling — Scala-based load testing with rich reports.

Use Postman for functionality; use the tools above for performance testing.

2. Cloud Account Requirement

Since Postman v10, the Scratch Pad (local-only mode) is gone; an account and cloud sync are required. This can conflict with strict corporate security policies.

How to handle it:

If your company restricts cloud storage, consider an older Postman (v9 or earlier) with Scratch Pad.
Alternatively, use tools that support local mode, such as Insomnia.
For large orgs, Postman offers Enterprise On-Premise for self-hosting.

3. High Resource Usage

Postman is built on Electron and can be resource-heavy, especially on older machines.

How to handle it:

Use the web version of Postman to reduce local load.
For simple requests, use lighter tools (e.g., Thunder Client) and keep Postman for automation/monitoring.

4. Paid Features & Free Plan Limits

Some features (advanced monitoring frequency, collection versioning, larger teams) require paid plans.

How to handle it:

Evaluate ROI for paid features (e.g., 5–10 minute monitors, version control).
Small teams can often rely on the free plan; upgrade only when needed.

5. Dependence on Postman’s Format & Ecosystem

Collections/environments use Postman’s JSON format. While open, migrating complex scripts to other tools may be time-consuming.

How to handle it:

Regularly export collections as JSON if migration is possible later.
Document complex scenarios to simplify potential migration.

Best Practices Given These Limits

Use Postman for functional testing and daily automation with WB API.
Complement it with specialized tools for load testing and strict security requirements.

Next, we’ll cover common mistakes when using WB API in Postman and how to fix them quickly.

Common WB API Issues in Postman — and How to Fix Them

Quick fixes for frequent problems that save time

As you use the WB API in Postman regularly, you’ll encounter some common errors. Here’s how to deal with the most frequent ones.

Error #1: “401 Unauthorized” or “403 Forbidden”

This occurs when your request fails authorization.

Possible causes:

Missing or invalid token.
Incorrect Authorization header.

Fix:

Check that you’ve added the Bearer token to your request.
Ensure there are no extra spaces, typos, or stray characters.
Verify the token is valid and not expired (tokens may need periodic renewal).

Correct header example:

Authorization: Bearer abcdef1234567890

Error #2: “422 Unprocessable Entity”

Usually means the request body is in the wrong format or doesn’t match API spec.

Possible causes:

Wrong request body format (e.g., number vs. string).
Missing required fields in JSON.

Fix:

Check WB API docs (Swagger) to ensure all required fields are present.
Validate JSON (e.g., with JSONLint).
Check data types: numbers without quotes; strings in quotes.

Correct JSON format example:

{ "productId": 123456, "price": 990.5, "currency": "RUB" }

Error #3: “500 Internal Server Error” from Wildberries

Indicates a server-side issue (temporary failure, overload, etc.).

Fix:

Wait briefly and retry.
Add retry logic via Postman scripts (Pre-request or Tests).

Simple retry script example:

if (pm.response.code === 500 && !pm.environment.get("retry")) {
  pm.environment.set("retry", true);
  postman.setNextRequest(pm.info.requestName);
} else {
  pm.environment.unset("retry");
}

This will retry the request once on a 500 error.

Error #4: Can’t Upload a File

File upload errors often stem from sending the request in the wrong format.

Fix:

In Postman, use Body → form-data.
Create a key with the field name from the docs (often file) and set type to File.
Ensure the request is POST and the URL matches the docs.

Example:

URL:

POST https://suppliers-api.wildberries.ru/api/v3/orders/upload

Body (form-data):

key: file | value: select your file

Error #5: Can’t Find Response Headers or Debug Info

Sometimes you need extra info (headers, response time, size).

How to find it:

Open the Headers tab below the response to see server-returned headers.
Open the Postman Console (Menu → View → Show Postman Console) to see full request/response details.

Error #6: SSL (TLS) Certificate Error

You may encounter SSL/TLS issues.

Possible causes:

Server certificate problems.
Client settings in Postman.

Fix:

Temporarily disable SSL verification in Postman (Settings → General → SSL certificate verification — OFF).
If it persists, the issue may be server-side.

Reduce Errors with These Tips

Always verify authorization and request body format.
Use Postman’s built-in tools (variables, tests, console) to troubleshoot quickly.
Add retry logic and monitoring to catch typical WB API issues automatically.

In the next section, we’ll wrap up with final recommendations for daily use so WB API integration brings maximum value with minimal distraction.

Next Steps & Additional Resources

How to Cement What You’ve Learned

Now that you know how to use Postman with WB API, don’t stop here. To make the most of it, here are concrete next steps and resources.

Useful Resources

Official WB API Documentation — the latest info on all API methods.
Postman Learning Center — detailed guidance from basics to complex automation.
GitHub Actions Documentation — learn how to automate testing with Newman.
Newman on GitHub — docs for the Postman CLI runner.