Test Below the UI: Your First API Tests in Python

TL;DR Testing only through the UI is slow, and it misses everything a user can do with curl: a disabled button stops nobody who calls the endpoint directly. API testing with Python puts your first real tests below the UI, in one language: the €50.00 edge as a pytest test, the order chain from login to delete, and the test that checks one user can't read another's order.

Do this: Pick one endpoint you test by hand today and write a pytest test that calls it as a second user. Expect 403 or 404.

Part 2 ended on BUG-311's 14:15 line: the API removed the code, and only the page got it wrong. You checked the API once, by hand. This part tests it every time, in code, without a browser.

The UI of the ShopLite checkout can hide the "Pay" button all it likes. Anyone with Postman can still send POST /checkout. If the rule lives only in the page, it isn't a rule.

The QA Skills Path, in seven parts:

1. The QA Skills Path for 2026: What to Learn, in What Order
2. Test Design Techniques: Pick the Few Tests That Find Bugs
3. Test Below the UI: Your First API Tests in Python (you are here)
4. Why Your UI Tests Flake, and the Fix for Web and Mobile
5. Green Tests, Broken Checkout: The Checks Functional Tests Miss
6. Quality Gates in CI: Make Your Tests Block a Bad Merge
7. AI in Testing: Use It Without Trusting It, and Test AI Features

One language, learned on the API

The repo's advice is short: learn one language before you automate anything. It has guides for Python, TypeScript, Java, C# and Go, and each ends with one real test. This series writes its code in Python 3.12 with pytest 8. Pick yours and stay with it.

The API is the right place to learn it. API tests run without a browser, so they are faster and less flaky than UI tests. They are also where business rules have to hold, because the API is what every client calls.

Your first test: the €50.00 edge

Part 2's boundary table becomes a parameterised test. The repo's version runs on its own, with a toy implementation of rule R3 in the same file:

# … imports and the toy apply_save10() from the repo
@pytest.mark.parametrize("subtotal, expected", [
    ("50.00", "45.00"),
    ("50.01", "45.01"),
])
def test_save10_applies_at_and_above_minimum(subtotal, expected):
    assert apply_save10(Decimal(subtotal)) == Decimal(expected)

def test_save10_rejected_just_below_minimum():
    with pytest.raises(ValueError, match="Minimum order"):
        apply_save10(Decimal("49.99"))

Run it with pip install pytest && pytest. parametrize turns one test into two, and the third value gets its own test because it expects an error. Note Decimal: testing money with floats is a boundary bug of its own, since 0.1 + 0.2 != 0.3.

Chain the checkout like a customer would

Testing one endpoint alone proves little. The repo's checklist chains the calls a real client makes, and the test fails if any link breaks:

sequenceDiagram
  participant A as Alice
  participant API as ShopLite API
  participant B as Bob
  A->>API: POST /login
  API-->>A: 200 + token
  A->>API: POST /orders
  API-->>A: 201 + order_id
  A->>API: GET /orders/{order_id}
  API-->>A: 200, same items
  B->>API: PUT /orders/{order_id}
  API-->>B: 403 Forbidden
  A->>API: DELETE /orders/{order_id}
  API-->>A: 204 No Content
  A->>API: GET /orders/{order_id}
  API-->>A: 404 Not Found

The last call matters. A 404 after the delete proves the record is gone, not left behind as a ghost row.

Two users, one order

The checklist calls broken object level authorisation (BOLA) the most common API vulnerability: user A's order is readable by user B because the API never checks who owns it. You only find it with two users:

# … BASE and login() as in the repo
def test_user_cannot_read_another_users_order():
    token_a = login("[email protected]", os.environ["QA_PASSWORD"])
    token_b = login("[email protected]", os.environ["QA_PASSWORD"])

    order = requests.post(
        f"{BASE}/orders",
        headers={"Authorization": f"Bearer {token_a}"},
        json={"items": [{"sku": "MUG-01", "qty": 1}]},
        timeout=10,
    ).json()

    r = requests.get(
        f"{BASE}/orders/{order['id']}",
        headers={"Authorization": f"Bearer {token_b}"},
        timeout=10,
    )
    assert r.status_code in (403, 404), f"Bob could read Alice's order: {r.status_code}"

Both codes pass; 404 also hides that the order exists. Write the same test for update and delete, and for every resource with an owner.

Each remaining row of the repo's API checklist is one more test on the checkout:

Try it

pip install pytest requests
pytest -v test_boundaries.py

The API is now covered, and it was never the problem: BUG-311 lives in the page, which shows €27.00 after the API has removed the code. A UI test has to wait for that total without sleep(5), and the same checkout runs in the ShopLite app on two phones. Part 4, Why Your UI Tests Flake, and the Fix for Web and Mobile, builds UI tests that turn red only for a real reason.

Read this with your AI

Read the post "Test Below the UI: Your First API Tests in Python".
1. I'll paste one endpoint from my API. List the checklist rows that apply to it.
2. Write a pytest test for its two-user authorisation case, with secrets from environment variables.
3. Tell me what my test would miss if the endpoint returned 200 with an empty body.