Playwright API testing uses the same framework, the same Playwright project/configuration, and the same test suite you already write UI tests in to send real HTTP requests, mock responses, and verify the resulting server-side state after a UI action. No second tool, no second test runner, no context-switching between a UI suite and an API suite that drift out of sync with each other.
That's the core shift this post covers: what changes when API testing stops being a separate discipline, how to set it up for pure API tests and for UI tests that need backend validation, and how this approach affects coverage, feedback, and CI cost.
The Problem: Two Test Suites, One Application
Most teams end up with API coverage and UI coverage living in different tools: Postman or a REST client for the API; Playwright or Selenium for the UI, because that's how the tooling has traditionally been split. That split has a cost:
Duplicated setup. Auth, base URLs, and test data creation get written twice, once per suite, and drift apart over time.
