Playwright + Python API Auth Flow Testing | Token, CRUD & Security Verification

📌 This article is for:

• Engineers who want to start API testing with Playwright’s APIRequestContext
• Developers interested in automating authentication flows (token acquisition, passing, and rejection)
• QA engineers who want to manage test data efficiently with pytest fixtures
• Anyone who wants to automate CRUD operations (POST, PUT, DELETE) against a REST API

✅ What you’ll learn in this article

• How to implement API tests using Playwright’s APIRequestContext
• How to manage and share auth tokens across tests using pytest fixtures
• Test implementations for GET / POST / PUT / DELETE HTTP methods
• How to verify that unauthenticated access is correctly rejected

👤

# Install Playwright + pytest
pip install playwright pytest pytest-playwright pytest-html

# Install Playwright browsers (optional for API-only tests)
playwright install

💡 Note: Playwright’s APIRequestContext does not launch a browser. For API-only testing, playwright install can be skipped — but it’s recommended if you plan to combine API and E2E tests later.

project/
├── pytest.ini          # ← place here
├── test_auth_flow.py
└── report.html         # ← auto-generated after each run

[pytest]
addopts = --html=report.html --self-contained-html

# With pytest.ini in place, no extra flags needed — report generates automatically
pytest test_auth_flow.py -v -s

✅ Benefit: No need to type --html=report.html every time. Settings are shared consistently across the whole team.

# STEP 2: Start a local server in the folder with report.html
python -m http.server 8080

# You'll see: Serving HTTP on 0.0.0.0 port 8080 ...

# STEP 3: Open this in your browser (type directly into address bar)
localhost:8080/report.html

✅ What you can see: PASS / FAIL list, execution time, error details, and print() output (when using -s flag)

💡 To stop the server: Press Ctrl + C in the terminal. python -m http.server is built into Python — no extra installation needed.

# Create APIRequestContext with a base_url
request_context = playwright.request.new_context(
    base_url="https://restful-booker.herokuapp.com"
)

# Now you can use just the path for requests
response = request_context.get("/booking")

response = request_context.post(
    "/auth",
    data={"username": "admin", "password": "password123"}
)

# Extract the token from the response JSON
token = response.json()["token"]
print(token)  # → "abc123xyz..."

# ✅ Cookie method (used in this article — Restful Booker)
headers = {"Cookie": f"token={token}"}

# Bearer method (common in most modern REST APIs)
# headers = {"Authorization": f"Bearer {token}"}

💡 Key point: Always check the API documentation to confirm which method is required. Using the wrong method will result in a 403 Forbidden response.

# GET request with auth header
response = request_context.get(
    "/booking/1",
    headers={"Cookie": f"token={token}"}
)

# Verify status code
assert response.status == 200, f"Expected 200 but got {response.status}"

# Verify response body
body = response.json()
assert body["firstname"] == "Taro", "firstname does not match expected value"

💡 Real-world Tip: These 4 patterns — create context → get token → set headers → send request & verify — are the complete foundation of REST API testing. Every test case in this article is a combination of these patterns.

@pytest.fixture(scope="session")
def api_request_context(playwright: Playwright) -> APIRequestContext:
    context = playwright.request.new_context(base_url=BASE_URL)
    yield context
    context.dispose()  # Automatically releases resources after all tests

💡 scope="session" reuses a single context across the entire test session — no reconnection overhead per test.

@pytest.fixture(scope="session")
def auth_token(api_request_context: APIRequestContext) -> str:
    response = api_request_context.post(
        "/auth",
        data={"username": USERNAME, "password": PASSWORD},
    )
    assert response.status == 200, "Failed to acquire token"
    token = response.json().get("token")
    assert token, "Response does not contain a token"
    return token

💡 The token is fetched once per session and reused across TC03–TC06. This is the DRY principle applied to test design.

@pytest.fixture(scope="session")
def booking_id(api_request_context: APIRequestContext, auth_token: str) -> int:
    response = api_request_context.post(
        "/booking",
        headers={"Content-Type": "application/json", "Accept": "application/json"},
        data="""{
            "firstname": "Taro",
            "lastname": "Yamada",
            "totalprice": 12000,
            "depositpaid": true,
            "bookingdates": {
                "checkin": "2025-01-01",
                "checkout": "2025-01-05"
            },
            "additionalneeds": "Breakfast"
        }""",
    )
    assert response.status == 200
    booking_id = response.json().get("bookingid")
    assert booking_id, "Failed to retrieve booking ID"
    return booking_id

💡 The booking is created once at the start of the session. TC03 (verify creation) → TC04 (update) → TC05 (delete) → TC06 (verify auth rejection) all reuse this same ID.

def test_tc01_login_success(api_request_context: APIRequestContext):
    """TC01: Token is acquired with valid credentials"""
    response = api_request_context.post(
        "/auth",
        data={"username": USERNAME, "password": PASSWORD},
    )

    assert response.status == 200, f"Expected 200 but got: {response.status}"

    body = response.json()
    assert "token" in body, "Response does not contain a token"
    assert len(body["token"]) > 0, "Token is empty"

    print(f"\n✅ TC01 PASS | Token acquired: {body['token']}")

✅ Verifications: Status 200 / token key exists in response / Token is not empty

def test_tc02_login_failure(api_request_context: APIRequestContext):
    """TC02: No token is issued with incorrect credentials"""
    response = api_request_context.post(
        "/auth",
        data={"username": USERNAME, "password": "wrongpassword"},
    )

    assert response.status == 200, f"Expected 200 but got: {response.status}"

    body = response.json()
    assert "token" not in body, "Token was returned despite wrong password"
    assert body.get("reason") == "Bad credentials", (
        f"Unexpected error message: {body.get('reason')}"
    )

    print(f"\n✅ TC02 PASS | Auth failure correctly detected: {body}")

⚠️ Important: This API returns status 200 even on auth failure (by design). The error is indicated in the response body via reason: "Bad credentials". Real-world APIs typically return 401 — always check the API spec.

def test_tc03_create_booking_with_token(
    api_request_context: APIRequestContext, auth_token: str, booking_id: int
):
    """TC03: A booking can be created with a valid auth token"""
    assert booking_id > 0, "Booking ID is invalid"

    print(f"\n✅ TC03 PASS | Booking created (BookingID: {booking_id})")

💡 Design note: The actual booking creation happens inside the booking_id fixture. TC03 simply confirms the fixture ran successfully — keeping the test itself minimal and clean.

def test_tc04_update_booking_with_token(
    api_request_context: APIRequestContext, auth_token: str, booking_id: int
):
    """TC04: A booking can be updated with a valid auth token"""
    response = api_request_context.put(
        f"/booking/{booking_id}",
        headers={
            "Content-Type": "application/json",
            "Accept": "application/json",
            "Cookie": f"token={auth_token}",  # Pass token via Cookie header
        },
        data="""{
            "firstname": "Hanako",
            "lastname": "Yamada",
            "totalprice": 15000,
            "depositpaid": false,
            "bookingdates": {
                "checkin": "2025-02-01",
                "checkout": "2025-02-07"
            },
            "additionalneeds": "Dinner"
        }""",
    )

    assert response.status == 200, f"Update failed: {response.status}"

    body = response.json()
    assert body.get("firstname") == "Hanako", "firstname was not updated"
    assert body.get("totalprice") == 15000, "totalprice was not updated"

    print(f"\n✅ TC04 PASS | Booking updated: {body}")

✅ Verifications: Status 200 / firstname updated to “Hanako” / totalprice updated to 15000

def test_tc05_delete_booking_with_token(
    api_request_context: APIRequestContext, auth_token: str, booking_id: int
):
    """TC05: A booking can be deleted with a valid auth token"""
    response = api_request_context.delete(
        f"/booking/{booking_id}",
        headers={"Cookie": f"token={auth_token}"},
    )

    assert response.status == 201, f"Delete failed: {response.status}"

    print(f"\n✅ TC05 PASS | Booking deleted (BookingID: {booking_id})")

⚠️ Important: Restful Booker returns status 201 on successful DELETE. Most REST APIs return 200 or 204 — always verify against the API specification before writing assertions.

def test_tc06_delete_booking_without_token(
    api_request_context: APIRequestContext, booking_id: int
):
    """TC06: A DELETE request without a token is rejected"""
    # The booking was deleted in TC05 — reuse the same ID to confirm auth rejection
    response = api_request_context.delete(
        f"/booking/{booking_id}",
        headers={},  # No Cookie — no auth
    )

    assert response.status == 403, (
        f"Delete succeeded without a token: {response.status}"
    )

    print(f"\n✅ TC06 PASS | Unauthenticated access correctly rejected: status={response.status}")

✅ Verification: Status 403 is returned for unauthenticated access. This is a fundamental security test pattern.

# Standard run
pytest test_auth_flow.py -v

# Include print() output
pytest test_auth_flow.py -v -s

📖 Related Articles

• 【Playwright】E2E Test Automation with SauceDemo (Beginner’s Guide)
• 【Selenium】Automate Login Form Validation Testing
• 5 Design Principles for Test Automation That Actually Lasts

📋 Key Takeaways

• Playwright’s APIRequestContext enables fast, browser-free API tests
• Auth tokens managed with scope="session" fixtures are shared across all tests efficiently
• POST, PUT, and DELETE HTTP method patterns are now in your toolkit
• Both negative (wrong password) and security (no-token rejection) test cases can be automated
• API status codes vary by implementation — always verify against the API spec before writing assertions

Playwright handles both E2E and API testing in one framework. Unifying your test stack means less context-switching and more time writing tests that matter.