Example Of API Testing: From Manual To CI Automation

A lot of teams start caring about API tests the same way they start caring about backups. Right after something painful happens.

You change one serializer field name, merge a harmless-looking PR, and a mobile client starts failing because it still expects the old response shape. Or a downstream billing service slows down and your endpoint technically still works, but only after the frontend times out. The bug report says “checkout broken.” The root cause is a tiny contract break nobody caught before deploy.

That’s where a good example of api testing stops being a toy snippet and starts becoming an engineering habit. The useful path is usually the same: poke the API manually first, turn the checks into repeatable assertions, automate the stable paths, then add the ugly scenarios most tutorials skip.

Why API Testing Is Non-Negotiable for Modern Backends

Backend failures often look small in code review and huge in production. A renamed field, stricter validation rule, missing null handling, or changed auth scope can break consumers without throwing obvious server errors. That’s why API testing belongs with normal backend work, not as a cleanup task for QA later.

The scale of API usage makes that unavoidable. The global API testing market was valued at USD 1.5 billion in 2023 and is projected to reach USD 12.4 billion by 2033, with a 23.5% CAGR, while nearly 90% of developers incorporate APIs into their applications, according to Market.us research on the API testing market. That matches what most of us see in practice. Almost every serious backend today exposes or depends on APIs, whether you’re running a Laravel monolith, a Node.js service, a Django app, or a GraphQL gateway.

Contract breaks are rarely loud

The dangerous bugs aren’t always 500 responses. Sometimes the endpoint returns 200 with the wrong structure. Sometimes auth still works, but object-level permissions don’t. Sometimes a dependency returns a shape you didn’t expect and your service passes corrupted data through to the client.

That’s also why API testing has to sit next to good design work. If your endpoints are inconsistent, ambiguous, or overloaded, your tests become messy and brittle. Clear contracts make both implementation and validation easier. A lot of those upstream decisions are covered well in these API design best practices for backend teams.

Practical rule: If another service, client app, or frontend depends on your response shape, every contract change deserves a test before it deserves a merge.

Reliable backends need multiple test layers

A strong API workflow usually includes:

• Manual exploration: Fast checks during development with curl or Postman.
• Automated regression tests: Repeatable request and response validation in CI.
• Negative tests: Invalid payloads, missing auth, wrong object ownership, malformed filters.
• Dependency-aware tests: Verifying behavior when upstream services are slow, unavailable, or inconsistent.

The mistake I see most often is stopping after the happy path. A GET /users/123 returning 200 is useful, but it tells you very little about how the system behaves under the failures that wake people up at night.

Manual API Testing From Curls to Postman Collections

Manual testing still matters. Not because clicking around scales, but because it helps you understand what the API is doing before you automate anything. Good automated suites usually start with a few careful manual calls.

Start with curl before you open a GUI

A plain curl request forces you to look at the basics: URL, method, headers, auth, payload, and raw response.

For a simple GET request:

curl -i 
  -H "Authorization: Bearer $TOKEN" 
  -H "Accept: application/json" 
  https://api.example.com/v1/users/123

What this gives you immediately:

• Status code: Did you get 200, 401, 403, or 404?
• Headers: Is content type what you expect? Are cache headers present?
• Body: Are the field names and null values correct?
• Auth behavior: Did your token work, or did middleware reject it?

For a POST request:

curl -i 
  -X POST 
  -H "Authorization: Bearer $TOKEN" 
  -H "Content-Type: application/json" 
  -d '{
    "name": "Ada Lovelace",
    "email": "[email protected]"
  }' 
  https://api.example.com/v1/users

If this fails, don’t rush into the app code yet. First compare request shape, content type, and required headers. A surprising number of “backend bugs” are malformed test requests.

Move to Postman when the requests stop being trivial

curl is perfect for quick checks, but it gets clumsy once you need multiple endpoints, environment switching, chained requests, or reusable auth tokens. That’s where Postman earns its place.

Postman is also common enough in real teams that it’s worth learning properly. The broader API tooling ecosystem reflects that. In the verified data, 40% of organizations use Postman for API documentation, testing, and inventory through the ecosystem described in the market data already referenced earlier.

Build a collection that mirrors real backend work

A clean Postman collection usually follows your resource model or business flow, not random ad hoc requests.

A practical structure:

• Auth
  • Login
  • Refresh token
• Users
  • Get user by ID
  • Create user
  • Update profile
• Orders
  • Create order
  • Get order
  • Cancel order
• Admin
  • List audit events
  • Disable user

Use environment variables for anything that changes by environment:

• base_url
• access_token
• admin_token
• user_id
• order_id

That lets you point the same collection at local, staging, or a temporary review app without editing every request manually.

Example Postman request setup

For GET {{base_url}}/v1/users/{{user_id}}:

• Method: GET
• Headers: Authorization: Bearer {{access_token}}
• Accept: application/json

For POST {{base_url}}/v1/users:

{
  "name": "Ada Lovelace",
  "email": "[email protected]"
}

The biggest improvement comes when you stop visually inspecting everything and start writing assertions in the Tests tab.

Add basic assertions in the Tests tab

A minimal Postman test script:

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

pm.test("content type is json", function () {
  pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json");
});

pm.test("response contains expected user fields", function () {
  const body = pm.response.json();
  pm.expect(body).to.have.property("id");
  pm.expect(body).to.have.property("email");
  pm.expect(body).to.have.property("name");
});

For a create endpoint:

pm.test("status is 201", function () {
  pm.response.to.have.status(201);
});

pm.test("created user email matches payload", function () {
  const body = pm.response.json();
  pm.expect(body.email).to.eql("[email protected]");
});

That’s enough to catch a lot of accidental breakage during local development.

Manual tests are best for discovery. They’re weak as a regression strategy unless you turn the checks into assertions and keep them organized.

Use Postman variables to chain requests

One useful pattern is saving values from one response for another request.

Example:

const body = pm.response.json();
pm.environment.set("user_id", body.id);

That lets your “Create User” request feed the ID into “Get User” or “Delete User” without copy-paste. At this stage, manual flows start becoming structured test assets instead of disposable debugging steps.

A simple API test case template

What manual testing is good at and what it isn’t

Manual API testing is strong at:

• Exploration: Understanding odd edge cases and undocumented behavior.
• Debugging: Verifying a fix quickly after a code change.
• Contract review: Checking whether an endpoint feels sane to consumers.

It’s weak at:

• Regression coverage: Humans miss things.
• Consistency: Different people validate different details.
• Speed at scale: Once your API grows, manual clicking becomes noise.

That’s the point where your best Postman checks should graduate into code.

Automating API Tests with Python Pytest and Requests

Manual checks help you discover behavior. Automation helps you keep behavior stable.

Python is a solid choice for API tests because requests is straightforward, pytest is clean, and the ecosystem is good for fixtures, mocking, and CI use. If your application team already uses Python anywhere in tooling or data work, it’s even easier to adopt. If you’re comparing stacks for API-heavy services, this broader Python API framework overview for backend teams is useful context.

Mature automation frameworks can achieve over 92% endpoint coverage and reduce testing cycles by up to 70% compared to manual GUI-based testing, while high-maturity organizations report defect escape rates below 1.5%, according to QASource’s API testing guide.

Convert one manual test into Python first

Start with something boring and stable. Don’t automate your messiest workflow first.

A direct translation of a Postman GET test:

import os
import requests

BASE_URL = os.environ["BASE_URL"]
TOKEN = os.environ["API_TOKEN"]

def test_get_user():
    response = requests.get(
        f"{BASE_URL}/v1/users/123",
        headers={
            "Authorization": f"Bearer {TOKEN}",
            "Accept": "application/json",
        },
        timeout=10,
    )

    assert response.status_code == 200
    data = response.json()
    assert data["id"] == 123
    assert "email" in data
    assert "name" in data

This is enough to prove the endpoint still works, but it won’t stay maintainable if you duplicate auth headers, setup logic, and payload generation everywhere.

Use pytest fixtures for setup and auth

Fixtures are where a test suite starts feeling professional.

Create conftest.py:

import os
import pytest
import requests

@pytest.fixture(scope="session")
def base_url():
    return os.environ["BASE_URL"]

@pytest.fixture(scope="session")
def auth_token():
    return os.environ["API_TOKEN"]

@pytest.fixture
def api_client(auth_token):
    session = requests.Session()
    session.headers.update({
        "Authorization": f"Bearer {auth_token}",
        "Accept": "application/json",
        "Content-Type": "application/json",
    })
    yield session
    session.close()

Then your test becomes smaller:

def test_get_user(api_client, base_url):
    response = api_client.get(f"{base_url}/v1/users/123", timeout=10)

    assert response.status_code == 200
    body = response.json()
    assert body["id"] == 123
    assert "email" in body

That matters once you have dozens of endpoints. One auth header change should happen in one place.

Parameterize validation instead of copy-pasting tests

If you want to validate several bad payloads, pytest.mark.parametrize is cleaner than writing a separate function for each one.

import pytest

@pytest.mark.parametrize(
    "payload, expected_status",
    [
        ({"name": "Ada"}, 400),
        ({"email": "[email protected]"}, 400),
        ({"name": "", "email": "[email protected]"}, 400),
        ({"name": "Ada", "email": "not-an-email"}, 400),
    ],
)
def test_create_user_rejects_invalid_payloads(api_client, base_url, payload, expected_status):
    response = api_client.post(f"{base_url}/v1/users", json=payload, timeout=10)
    assert response.status_code == expected_status

That style scales well because the test logic stays fixed while the input matrix grows.

Handle authenticated workflows explicitly

A lot of flaky test suites hide auth behind magic. Don’t do that. Make it obvious how the token exists and which role it represents.

For example, separate fixtures for a normal user and an admin:

@pytest.fixture(scope="session")
def user_token():
    return os.environ["USER_TOKEN"]

@pytest.fixture(scope="session")
def admin_token():
    return os.environ["ADMIN_TOKEN"]

@pytest.fixture
def user_client(user_token):
    session = requests.Session()
    session.headers.update({"Authorization": f"Bearer {user_token}"})
    yield session
    session.close()

@pytest.fixture
def admin_client(admin_token):
    session = requests.Session()
    session.headers.update({"Authorization": f"Bearer {admin_token}"})
    yield session
    session.close()

That makes authorization tests much easier to read.

Keep auth visible in tests. If a reader can’t tell which identity a request uses, they can’t reason about permission failures.

Mock dependent services when isolation matters

In microservices, your API often depends on another API. If that downstream service is unstable, your tests become unstable too.

A common pattern is to patch the code path that fetches the dependency. Suppose your endpoint calls billing_client.get_customer_status(customer_id) internally. You can mock that in a service-layer test.

def test_subscription_endpoint_handles_billing_status(client, mocker):
    mocker.patch(
        "app.services.billing_client.get_customer_status",
        return_value={"status": "active"}
    )

    response = client.get("/v1/subscription/123")

    assert response.status_code == 200
    assert response.json()["billing_status"] == "active"

And a failure case:

def test_subscription_endpoint_handles_billing_timeout(client, mocker):
    mocker.patch(
        "app.services.billing_client.get_customer_status",
        side_effect=TimeoutError("billing unavailable")
    )

    response = client.get("/v1/subscription/123")

    assert response.status_code in (502, 503)

The exact status code depends on your contract. What matters is that your service fails predictably and doesn’t expose raw internals.

Organize tests by behavior, not by framework

A maintainable structure often looks like this:

• tests/test_users.py
• tests/test_orders.py
• tests/test_auth.py
• tests/test_permissions.py
• tests/test_contracts.py

Avoid structures like tests/test_get.py and tests/test_post.py. HTTP verbs aren’t the thing your team reasons about. Business capabilities are.

A practical automation baseline

For a mid-sized backend, a useful automated suite usually covers:

1. Core CRUD behavior for the important resources.
2. Authentication and authorization checks.
3. Validation failures for malformed or incomplete payloads.
4. Contract assertions on response shape.
5. Dependency behavior with mocks for timeouts and invalid upstream data.

If you only automate one class of tests at first, automate the checks that guard revenue, auth, and shared contracts. Those are the regressions that spread fastest when they slip through.

Beyond Happy Paths Advanced and Negative Testing Examples

A 200 OK in Postman is how teams get a false sense of safety. Production failures usually show up somewhere else. A mobile client sends an old payload shape, a dependency returns garbage, a token is valid but points at the wrong tenant, or an upstream timeout turns a simple read into a partial outage.

Specmatic points to dependency issues as a major source of API failures in practice, which matches what backend teams see during incidents. That is why a useful API testing workflow has to extend past happy-path checks and cover bad inputs, contract drift, auth edge cases, and failure behavior for the services your endpoint depends on, as discussed in Specmatic’s write-up on API failure patterns and resiliency testing.

Validate shape, not just fields you happen to notice

Checking status_code == 200 and assert "id" in body catches very little. If a field changes type, disappears for one client version, or starts arriving under a different key, those lightweight assertions often still pass.

Schema validation gives you a tighter contract check:

from jsonschema import validate

user_schema = {
    "type": "object",
    "required": ["id", "name", "email"],
    "properties": {
        "id": {"type": "integer"},
        "name": {"type": "string"},
        "email": {"type": "string"},
    },
    "additionalProperties": True,
}

def test_get_user_matches_schema(api_client, base_url):
    response = api_client.get(f"{base_url}/v1/users/123", timeout=10)
    assert response.status_code == 200

    body = response.json()
    validate(instance=body, schema=user_schema)

I usually keep additionalProperties=True early on unless the API contract is tightly controlled across clients. Locking every field too soon creates noisy failures during harmless response expansion. For public APIs or shared internal contracts, stricter schemas are often worth the maintenance cost.

Negative tests that catch expensive bugs

Negative tests pay off fastest when they target failure modes your handlers already struggle with. Validation logic is one obvious area, but auth and ownership checks are usually where teams have the most painful misses.

Start with cases that map to real support tickets and incident notes:

• Missing required fields
• Invalid types
• Boundary values
• Unsupported enum values
• Malformed pagination params
• Expired or missing tokens
• Foreign resource access

Example for invalid data types:

import pytest

@pytest.mark.parametrize(
    "payload",
    [
        {"name": 123, "email": "[email protected]"},
        {"name": "Ada", "email": False},
        {"name": None, "email": "[email protected]"},
    ],
)
def test_create_user_rejects_invalid_types(api_client, base_url, payload):
    response = api_client.post(f"{base_url}/v1/users", json=payload, timeout=10)
    assert response.status_code == 400

Boundary test for pagination:

@pytest.mark.parametrize("page_size", [0, -1, "abc"])
def test_list_users_rejects_invalid_page_size(api_client, base_url, page_size):
    response = api_client.get(
        f"{base_url}/v1/users",
        params={"page_size": page_size},
        timeout=10,
    )
    assert response.status_code == 400

These cases are boring to write. They still catch the kind of regressions that break clients after a refactor.

One more practical point. Assert the error contract too, not just the status code. If your API is supposed to return a stable validation shape, test for that shape. Frontend and mobile clients often depend on those error keys just as much as they depend on success payloads.

Test dependency failures on purpose

Endpoints rarely fail in isolation. They fail because Redis is slow, the billing provider returns a 200 with missing fields, or an internal service starts timing out after a deploy. If you only test with healthy dependencies, you are missing the path that causes the incident.

These are high-value dependency scenarios to cover:

• the dependency times out
• the dependency returns malformed JSON
• the dependency returns a valid body with an unexpected business state
• the dependency returns a 5xx
• the dependency is slow enough to trigger your timeout budget

A mocked timeout test:

def test_order_summary_returns_gateway_error_when_inventory_service_times_out(client, mocker):
    mocker.patch(
        "app.integrations.inventory.fetch_stock_levels",
        side_effect=TimeoutError("inventory timeout"),
    )

    response = client.get("/v1/orders/123/summary")

    assert response.status_code in (502, 503)

Mocking is the right tool here because it gives you repeatable failures. Live integration environments are still useful, but they are a bad place to depend on rare timing behavior. I use mocks to prove application behavior and a smaller set of environment tests to confirm wiring, credentials, and network assumptions.

Security testing for object-level authorization

A valid token proves identity. It does not prove the caller owns the resource they are asking for.

This is the class of bug that slips through teams that only test login success and role checks. Object-level authorization needs explicit coverage, especially on endpoints with path IDs, account IDs, tenant IDs, or nested resources.

A practical BOLA-style check:

def test_user_cannot_access_another_users_invoice(user_a_client, user_b_invoice_id, base_url):
    response = user_a_client.get(
        f"{base_url}/v1/invoices/{user_b_invoice_id}",
        timeout=10,
    )

    assert response.status_code in (403, 404)

Use at least two authenticated clients in these tests. One for the owner, one for a different user in the same product context. In multi-tenant systems, add a cross-tenant case too. That is often where authorization middleware and repository filters drift apart.

Performance checks need representative traffic

Performance testing belongs in the workflow, but it solves a different problem from functional tests. The useful version answers questions like: which endpoints degrade first, which query paths are expensive, and what failure pattern shows up under sustained load?

A few practices hold up well in real systems:

• Test a realistic endpoint mix: Include writes, searches, and aggregation-heavy reads.
• Ramp traffic in stages: Gradual load increases make saturation points easier to spot.
• Track latency and error shape together: Rising p95 without errors tells a different story than a sudden jump in 5xx responses.
• Include awkward endpoints: Export, reporting, and filter-heavy routes usually crack before the easy CRUD paths.

That gives you a workflow with actual coverage: manual exploration to understand behavior, automated contract and negative tests to stop regressions, and targeted dependency and load checks for the failure paths that usually reach production first.

Integrating API Tests into Your CI/CD Pipeline

A test suite that only runs when someone remembers to run it is a comfort blanket, not a safety system. The useful version runs on every push, fails loudly, and treats regressions as build problems.

Security is a good reason to wire this up early. Broken object-level authorization is a leading OWASP API risk and causes 80% of breaches in modern APIs, while fewer than 10% of online API testing examples show how to test those granular permission flaws, according to Beagle Security’s API security testing write-up. Those checks shouldn’t live in a forgotten local script. They should block merges.

A practical GitHub Actions workflow

This example runs both Python pytest tests and a Postman collection through Newman.

name: API Test Pipeline

on:
  push:
    branches:
      - main
      - develop
  pull_request:

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

    env:
      BASE_URL: ${{ secrets.BASE_URL }}
      API_TOKEN: ${{ secrets.API_TOKEN }}
      USER_TOKEN: ${{ secrets.USER_TOKEN }}
      ADMIN_TOKEN: ${{ secrets.ADMIN_TOKEN }}

    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install Python dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run pytest suite
        run: pytest -q

      - name: Set up Node.js for Newman
        uses: actions/setup-node@v4
        with:
          node-version: "20"

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

      - name: Run Postman collection
        run: |
          newman run postman/collection.json 
            -e postman/github-actions-environment.json 
            --env-var "base_url=${{ secrets.BASE_URL }}" 
            --env-var "access_token=${{ secrets.API_TOKEN }}"

Keep secrets out of the repo

Never hardcode tokens, API keys, or environment URLs in test files or workflow YAML. Use GitHub Secrets for:

• Base URLs for staging or review environments
• Bearer tokens for test identities
• Admin credentials when admin-only routes need validation

This matters for security, but also for portability. A clean CI setup should be able to run against different environments by swapping secret values, not by editing committed files.

CI should answer one question fast: did this change break the contract, permissions, or critical flows?

Mix fast and slow tests intentionally

Not every API test belongs on every push. A useful split looks like this:

• Fast suite on pull requests: Core contract, auth, permissions, validation.
• Broader suite on main or nightly runs: Full workflow coverage, external dependency checks, heavier integration scenarios.
• Performance and soak tests outside the main PR path: Important, but usually too expensive for every commit.

That split keeps feedback quick without turning the pipeline into a bottleneck.

A walkthrough can help if you’re setting this up for the first time:

Treat failures as engineering signals, not CI noise

A failing API test in CI usually points to one of four things:

1. You changed the contract intentionally and need to update tests and consumers.
2. You changed behavior unintentionally and the test just saved you.
3. The environment is unstable and the test should isolate or mock more aggressively.
4. The test is weakly designed and needs better setup, teardown, or data control.

The workflow itself isn’t the hard part. The hard part is deciding that red builds deserve action every time.

Troubleshooting Common Issues and Final Best Practices

A test suite usually looks healthy right up until release day. Then CI fails on a timeout nobody can reproduce locally, staging rejects a request with a 415, or a "simple" auth check breaks because one shared test user had the wrong role. That is the point where API testing stops being a checklist and starts looking like backend engineering.

The hard part is maintenance. Writing the first few happy-path checks in Postman or pytest is easy. Keeping a larger suite trustworthy means controlling timing, data, auth, and dependencies so a red test points to a real regression instead of noise.

Flaky tests usually come from timing and shared state

If a test passes on rerun, assume the setup is weak until proven otherwise. I usually see four causes: background jobs that have not finished yet, assertions that race eventual consistency, shared records mutated by other tests, and live calls to third-party services.

A few fixes hold up well in production:

• Poll only for async workflows that you own. If the endpoint starts a job, poll for job completion with a timeout and clear failure message. Do not scatter sleep(5) through the suite.
• Mock dependencies at the boundary. If you are testing your order API, fake the payment provider response unless the goal of that test is provider integration.
• Create data per test run. Unique emails, order IDs, and tenant names remove a lot of random failures.
• Tear down aggressively or use disposable environments. Orphaned data creates weird failures three builds later.

Negative tests help here too. They often expose race conditions faster than happy paths because retries, duplicate submissions, and invalid state transitions hit the edges of your implementation.

Local passes and CI failures usually mean environment drift

Start with the boring checks. Python version, dependency lockfile, database schema, feature flags, seeded fixtures, and environment variables cause a lot of "works on my machine" failures.

Make the failure output useful. Log the request method, URL, headers you can safely print, body, status code, and response payload for failed assertions. Many "mysterious" failures turn out to be expired tokens, missing seed data, or a bad Content-Type header. If your team hits that class of issue often, this guide to the unsupported media type error in backend APIs is a good reference.

Auth deserves special attention. Tests that share one admin token tend to hide permission bugs. Use separate identities for normal users, admins, and service accounts, then assert both allowed and forbidden behavior. Production incidents often come from the forbidden case nobody tested.

Thin coverage creates false confidence

A green suite does not mean much if it only checks login and one read endpoint. The gaps that hurt in production are usually negative cases, permission boundaries, idempotency, and dependency failures.

Cover the flows that are expensive to break:

• contract checks for request and response shape
• auth and role-based access
• validation failures for bad input
• duplicate request handling
• timeouts and upstream error mapping
• critical write paths with database side effects

That is the workflow that holds together. Start by exploring the API manually with curl or Postman so you understand the contract and failure modes. Automate the stable paths with pytest and requests. Add negative cases before you declare a feature "covered." Mock unstable dependencies so CI stays reliable, then keep a smaller set of true integration tests for the places where the wire-level behavior matters.

Checklist that holds up in practice

Start with manual exploration: Use curl or Postman to understand the real contract before automating it.

Automate stable paths first: Auth, critical reads and writes, and shared contracts should be in CI early.

Test bad inputs on purpose: Missing fields, wrong types, invalid pagination, and expired tokens catch real bugs.

Mock dependencies when isolation matters: Don’t let another service’s instability make your suite meaningless.

Separate identities clearly: Permission tests only work when user roles and ownership are explicit.

Make failures easy to debug: Log enough request and response detail to explain red builds quickly.

Keep environments consistent: The same assumptions should hold locally, in CI, and in staging.

Treat tests as product code: Refactor them, review them, and delete weak ones before they rot.

A good example of api testing is not one request and one assertion. It is a workflow that starts with manual exploration, grows into repeatable Python checks, and keeps adding the ugly cases. Invalid input. bad auth. broken dependencies. duplicate requests. Those are the cases that keep bad releases out of production.

Backend engineers who want more practical guides on API design, framework choices, testing workflows, and backend architecture can explore Backend Application Hub. It’s a strong resource when you need implementation-focused backend content without the usual hand-wavy advice.