Pytest with the requests library is the classic combination for API testing in Python. Requests is the library that made HTTP in Python simple and readable, and Pytest is the test runner that most Python teams settle on. Together they give you a way to test an API that is easy to read, quick to run and comfortable for anyone who already writes Python.
How it works
You send a request with the requests library and assert on the result with plain Python assert statements. There is no special assertion language to learn, because the checks are ordinary comparisons:
def test_should_return_access_token_on_successful_login(base_url):
payload = {"email": "[email protected]", "password": "welcome01"}
response = requests.post(f"{base_url}/users/login", json=payload)
assert response.status_code == 200
response_body = response.json()
assert "access_token" in response_body, "Response does not contain 'access_token'"
The base URL comes from a fixture, so the value lives in one place and every test reads it. Pytest fixtures also handle shared setup, so a login fixture can produce a token that protected tests reuse. You run everything with pytest, and this project writes an HTML report through the pytest-html plugin.
Benefits
The code is about as readable as API testing gets. Requests has a clean interface, plain assert statements keep the intent obvious, and Pytest fixtures give you real structure for setup and reuse without much ceremony. The feedback loop is fast because there is no compilation, and the ecosystem around Pytest is enormous, so plugins exist for reporting, parallel runs, retries and much more. For a Python team this is a natural home for API tests.
Downsides
Plain assert statements are simple, but they do not give you JSON path queries or schema validation unless you add a library for that. Requests is synchronous, so a suite that makes many slow calls will not overlap them without extra work. As always with a bare bones stack, you get little structure for free, so you decide how to organise fixtures and helpers as the suite grows. None of this is a real obstacle, but it is worth knowing before you start.
What the example project tests
The repository at github.com/testsmith-io/api-test-automation-python-pytest-requests tests the Practice Software Testing API at https://api.practicesoftwaretesting.com, the ToolShop backend used across this series. The base URL is configured in pytest.ini and delivered through a fixture.
Three scenarios are covered. A brands test calls GET /brands and checks for status 200 with at least two entries. A login test posts credentials to /users/login and confirms the access_token. A protected invoices test logs in through a fixture, sends the Bearer token to GET /invoices, and checks the returned list. A GitHub Actions workflow runs pytest and saves the HTML report. The scenarios match the Playwright based Python example, so you can compare the requests library against Playwright's request context in the same language.