How I test an API before the UI is ready

On most teams the backend ships an endpoint, and then QA waits — sometimes weeks — for a screen to click before "testing starts." That wait is wasted time, and worse, it pushes every API bug discovery to the most expensive possible moment: after the UI is built on top of it. Testing the API directly, before the UI exists, is the most concrete form of shift-left I know. Here's how I actually do it, as a habit, not a project.

Start from the contract, not the screen

Before there's a UI, the contract is the spec. Get the OpenAPI/Swagger doc, the schema, or even a Slack message describing the endpoint, and read it as a tester: what are the required fields, the types, the constraints, the error cases? Reviewing the contract itself often surfaces bugs before a single request — a missing validation rule, an ambiguous field, an error case nobody defined. That review is testing.

Build the requests by hand

A REST client (Postman, Bruno, curl) is all you need. Recreate what the UI will eventually send: the happy-path create, the read, the update, the delete. Now you have a working loop against the real endpoint with no frontend in sight. This is also where you discover the contract and the implementation already disagree.

Run the bug pass the UI will never trigger

This is the payoff. The UI, when it arrives, will only ever send well-formed, validated, happy-path requests — so a huge class of bugs is invisible from the screen and wide open at the API. Run the 12-bug pass now:

• Missing/invalid/oversized fields the form will later prevent
• Wrong status codes and 200-wrapped errors
• Auth gaps: no token, another user's token
• Pagination, filtering, sorting edges
• Duplicate creates and idempotency

Every bug you find here is one that won't turn into a confusing UI bug later, where it's ten times harder to localise.

Use the API to set up state you couldn't reach yet

Even before the UI, the API lets you create the awkward states you'll want later: an account with 10,000 records (to test pagination and performance), an order in a weird status, a user with no permissions. You're building your test data toolkit early — and these same calls become your seed/setup helpers once UI automation starts.

Mock what isn't there yet

If your endpoint depends on another service that also isn't ready, a stub or mock keeps you moving — and doubles as a way to force error responses (timeouts, 500s, malformed payloads) that are hard to trigger against the real thing. Testing how your API behaves when its dependency misbehaves is a check the UI can never drive.

Hand the frontend team a head start

When you test the API first, you're not just finding bugs early — you're handing the frontend team a verified, documented contract. "These fields are validated, these errors come back in this shape, here's a working request for each case" saves them guessing and prevents the UI from being built against a buggy backend. It changes QA from a gate at the end to a contributor at the start.

Where this fits

This is shift-left as a daily habit, not a methodology slide. It leans on the 12 API bugs, status codes, and the list-endpoint pass. The API testing checklist structures it and the tools directory compares Postman, Bruno, REST Assured, and Karate.

Testing an API before the UI

• Review the contract (OpenAPI/schema) as a spec — bugs surface before any request
• Rebuild the requests the UI will eventually send, by hand
• Run the full bug pass the UI can't trigger (bad input, auth, pagination, duplicates)
• Use the API to create awkward test states (large accounts, odd statuses) early
• Mock missing dependencies — and use them to force error responses
• Hand the frontend a verified contract with working requests per case