Postman vs Old Tools What Changed for Python Developers

# The old way — test a POST endpoint with curl

curl -X POST https://api.example.com/v1/orders \
  -H "Authorization: Bearer eyJhbGciOi..." \
  -H "Content-Type: application/json" \
  -H "X-Request-Id: 550e8400-e29b-41d4-a716-446655440000" \
  -d '{"productId": 123, "quantity": 2}'

# Then copy the response.
# Then change the token because it expired.
# Then repeat for every endpoint.
# Then repeat again for staging.

# This is where most of the day went.
# Not testing logic — managing strings.

# The old way — same endpoint, but in Python

import requests

token = "eyJhbGciOi..."   # where does this come from?
base = "https://api.example.com"

headers = {
    "Authorization": f"Bearer {token}",
    "Content-Type": "application/json",
}

payload = {"productId": 123, "quantity": 2}

response = requests.post(
    f"{base}/v1/orders",
    json=payload,
    headers=headers,
    timeout=10,
)

assert response.status_code == 201
order_id = response.json()["id"]

# Now you need the same request again in your test file.
# And again for the staging environment.
# And again for the auth flow.
# Three copies. Three drift points. Three bugs.

# What a request looks like inside a Postman collection
# (this is saved in a single JSON file you can commit)

{
  "name": "Create Order",
  "request": {
    "method": "POST",
    "header": [
      { "key": "Authorization", "value": "Bearer {{token}}" },
      { "key": "Content-Type", "value": "application/json" }
    ],
    "url": {
      "raw": "{{base_url}}/v1/orders",
      "host": ["{{base_url}}"],
      "path": ["v1", "orders"]
    },
    "body": {
      "mode": "raw",
      "raw": "{\"productId\": 123, \"quantity\": 2}"
    }
  }
}

# {{token}} and {{base_url}} are variables.
# They come from the environment, not from this file.
# Change environment → the same request hits dev or staging.
# No code changes. No drift.

// Pre-request script — runs automatically before every request
// This is what used to be a manual "get a token" step

const baseUrl = pm.environment.get("base_url");

pm.sendRequest({
    url: `${baseUrl}/auth/token`,
    method: "POST",
    header: { "Content-Type": "application/json" },
    body: {
        mode: "raw",
        raw: JSON.stringify({
            client_id: pm.environment.get("client_id"),
            client_secret: pm.environment.get("client_secret")
        })
    }
}, function (err, res) {
    if (err) {
        console.error(err);
        return;
    }
    pm.environment.set("token", res.json().access_token);
});

// Tests tab — assertions live with the request
pm.test("Status is 201", function () {
    pm.response.to.have.status(201);
});

pm.test("Response has an order id", function () {
    const body = pm.response.json();
    pm.expect(body).to.have.property("id");
    pm.environment.set("order_id", body.id);
});

// That is the whole shift.
// Token refresh and assertions used to be a Python file.
// Now they live inside the collection.

# Everything in this file is still valid and still useful
# Postman did not delete any of it

import os
import requests
import pytest

BASE = os.environ.get("BASE_URL", "https://api.example.com")
TOKEN = os.environ.get("API_TOKEN")


def auth_headers():
    return {"Authorization": f"Bearer {TOKEN}"}


def test_create_order():
    payload = {"productId": 123, "quantity": 2}
    response = requests.post(
        f"{BASE}/v1/orders",
        json=payload,
        headers=auth_headers(),
        timeout=10,
    )
    assert response.status_code == 201
    assert "id" in response.json()


# Run with: pytest test_orders.py -v
# This is still the right tool for CI tests.
# Postman is not going to replace it.

Where Python code still beats Postman, every time:

☐ Complex business logic in the test
   → "retry three times if status is 429"
   → "loop over 1000 ids and assert each"

☐ File uploads with real multipart handling
   → requests makes this trivial
   → Postman can do it but is clumsy for parametrised files

☐ Database verification after the API call
   → pytest fixture queries Postgres directly
   → Postman has no DB access without extra setup

☐ Async and concurrent testing
   → httpx + asyncio tests 500 endpoints in parallel
   → Postman UI is single-request

☐ Very fine-grained timing and concurrency
   → time.perf_counter around requests
   → Postman is not a load-testing tool

Rule of thumb:
Postman explores, Python asserts.
Postman is the fastest way to find a bug.
Python is the fastest way to prove it is fixed — on every build.

# Postman has a "Code" button on every request.
# Click it → choose Python → requests
# You get this, ready to paste into a pytest file:

import requests

url = "https://api.example.com/v1/orders"

payload = {"productId": 123, "quantity": 2}
headers = {
    "Authorization": "Bearer YOUR_TOKEN",
    "Content-Type": "application/json",
}

response = requests.post(url, json=payload, headers=headers)
print(response.text)

# That is the whole bridge.
# Explore in Postman → generate the Python → assert in pytest.
# No copy-pasting a curl command and fixing the quotes.

When Python is the right choice (not Postman):

Situation 1 — Parameterised data
☐ You have a CSV of 200 test cases
☐ pytest runs each row as a test
☐ Postman is clumsy with large parametrised files

Situation 2 — Retry and timing
☐ "retry on 429 with exponential backoff"
☐ Postman pre-request scripts can do it, but
   the code becomes unmaintainable

Situation 3 — Real load
☐ 500 parallel requests to measure p99
☐ Postman is a single-request client
☐ httpx + asyncio (or locust) is the right tool

Situation 4 — Cross-service verification
☐ Call the API, then check the DB
☐ Call the API, then check a Kafka topic
☐ Postman has no native DB or Kafka support

Rule: Postman for one-off and exploration.
Python for logic, data and scale.

# A realistic day for a Python developer

Morning
☐ New endpoint added to the API
☐ Open Postman
☐ Send a request, check the JSON
☐ Save it to the "orders" collection
☐ Add 3 tests in the Tests tab
   - 201 status
   - order id present
   - total price correct

Afternoon
☐ Click "Code" → Python → requests
☐ Paste into test_orders.py
☐ Change hardcoded values to pytest fixtures
☐ Run pytest locally

End of day
☐ Push branch
☐ CI runs Newman on the collection
☐ CI runs pytest on the assertions
☐ Both green → PR merges

This is the workflow real teams use today.
It uses both tools, not one.

What actually gets committed to the repo:

api-tests/
├── postman/
│   ├── orders.postman_collection.json
│   ├── auth.postman_collection.json
│   ├── dev.postman_environment.json
│   └── staging.postman_environment.json
├── tests/
│   ├── test_orders.py
│   ├── test_auth.py
│   └── conftest.py
├── .github/workflows/
│   └── api-tests.yml
└── README.md   (how to run both)

Rules:
☐ Never commit a real token — use environment files with placeholders
☐ Never commit a Postman cloud export with secrets
☐ Use Postman's export → sanitise → commit
☐ Keep collection names stable — CI references them

If a reviewer cannot run your tests from a fresh clone,
the collection is not ready to be committed.

# Run a Postman collection from the command line
# This is what used to require a separate Python script

npm install -g newman

newman run postman/orders.postman_collection.json \
  -e postman/dev.postman_environment.json \
  --reporters cli,json \
  --reporter-json-export reports/newman.json

# Or with an inline env override
newman run postman/orders.postman_collection.json \
  --env-var "base_url=https://staging.example.com" \
  --env-var "token=$STAGING_TOKEN"

# Exit code 0 = all tests passed
# Exit code 1 = at least one test failed
# That is all CI needs to fail a build.

# .github/workflows/api-tests.yml

name: API Tests

on:
  pull_request:
    branches: [main]

jobs:
  newman:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Install Newman
        run: npm install -g newman

      - name: Run collection
        env:
          BASE_URL: ${{ secrets.STAGING_BASE_URL }}
          API_TOKEN: ${{ secrets.STAGING_API_TOKEN }}
        run: |
          newman run postman/orders.postman_collection.json \
            --env-var "base_url=$BASE_URL" \
            --env-var "token=$API_TOKEN" \
            --reporters cli,json \
            --reporter-json-export newman-report.json

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: newman-report
          path: newman-report.json

# Every pull request runs the collection.
# No separate test code. No drift between what you tested
# in Postman and what CI tests.