Cypress is known as a browser testing tool, but it is also a capable API client through its cy.request command. That command sends a real HTTP request outside the browser, so you can test endpoints directly without loading a page. For a team that already runs Cypress against the front end, adding a handful of API checks means staying in a tool and a language they know well, which is TypeScript in this project.
How it works
You call cy.request with a method, a URL and an optional body or headers, then assert on the response inside a then block using Chai style expectations. A base URL in the config keeps the paths short. Here is the protected flow, which logs in once and reuses the token:
before(() => {
cy.request('POST', `/users/login`, credentials).then((response) => {
expect(response.status).to.eq(200);
accessToken = response.body.access_token;
});
});
it('should retrieve invoices with a valid token', () => {
cy.request({ method: 'GET', url: `/invoices`,
headers: { Authorization: `Bearer ${accessToken}` },
}).then((response) => {
expect(response.status).to.eq(200);
expect(response.body.data).to.have.length.gte(15);
});
});
Specs live under cypress/e2e, the base URL is set in cypress.config.ts, and you run the suite headless with npx cypress run. Results can be turned into an HTML report through mochawesome.
Benefits
The main benefit is reuse of skills and setup. A front end team gets API tests in the same repository, the same language and the same runner they already use, with a familiar assertion style. The Cypress runner gives clear output and good error messages, and cy.request automatically handles a lot of the plumbing. For smoke checks that sit next to browser tests, this keeps everything in one place.
Downsides
Cypress is built around the browser, and its command chaining model is designed for that world, so using it purely as an API client can feel like using a large tool for a small job. The commands are asynchronous and chained rather than plain async and await, which some people find awkward for request only tests. If you have no browser tests at all, a dedicated HTTP library is lighter and more direct. Cypress shines when API checks live alongside UI tests, not as a standalone API framework.
What the example project tests
The repository at github.com/testsmith-io/api-test-automation-ts-cypress tests the Practice Software Testing API at https://api.practicesoftwaretesting.com, the ToolShop backend used throughout this series. The base URL is set in cypress.config.ts.
Three specs are covered. A brands spec calls GET /brands and checks for status 200 with at least two entries. A login spec posts credentials to /users/login and confirms the access_token. A protected invoices spec logs in first, sends the Bearer token to GET /invoices, and checks the returned list. A GitHub Actions workflow runs the suite and produces mochawesome results. The scenarios match the other TypeScript examples, so you can compare Cypress against Playwright and against Jest with Supertest on identical ground.