How to Do End to End API Testing: Journeys, Data and Checks

This is lesson 6.6 of Test Data, Mocks and End-to-End API Testing. Lessons 6.3 to 6.5 prepared the data; now you use it across a whole journey. For the workflow editor itself, see lesson 9.8; this lesson is about deciding what to build.

How to do end to end API testing

Here's how to do end to end API testing in one line: pick a business journey, run its calls in order, carry each step's output into the next, check every step, and finish by reading back what the journey wrote. The hard parts aren't the calls. They're choosing which journeys deserve a test, keeping the data between steps straight, and proving the final state rather than trusting a row of green status codes.

What is end to end API testing?

An end to end API test follows a journey the business cares about, such as "a new shopper orders a product and the order moves to processing", through every API call it takes. It's the API-level version of what a user does in the app, without the UI.

API testing vs end to end testing

Both are needed. The single-endpoint suite catches most bugs cheaply; the journeys catch the bugs that only appear when calls follow each other.

Six steps, on the sandbox store

1. Pick the journey from requirements. The sandbox's requirements document lists ten end-to-end scenarios, E2E-01 to E2E-10. E2E-01 is the shopper-to-fulfilment lifecycle: create a user, list a product, order it, read it back, move it to processing and on to completed.

2. Write the steps with their data. For a short version:

Try step 2 by hand:

curl -X POST 'https://demo.totalshiftleft.ai/api/v1/orders' \
  -H 'Content-Type: application/json' \
  -d '{"user_id":"11111111-1111-1111-1111-111111111111","product_id":"aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa","quantity":2}'

3. Assert at every step. Step 1: 201, and role defaulted to user. Step 2: 201, status is pending, quantity is 2. Step 3: 200, status is processing.

4. Read back the result. The last step checks the state the journey left behind, through a different call than the one that wrote it: the order's status is processing, its user is the one step 1 created, its product is the Wireless Mouse. A read-back like this is what turns a sequence of calls into evidence:

curl -X GET 'https://demo.totalshiftleft.ai/api/v1/orders/dddddddd-dddd-dddd-dddd-dddddddddddd?expand=user,product'

5. Own the data. The journey creates its own user and order, so it can't collide with another test, and it uses a seeded product it never changes. Reset or clean up as part of the suite (lesson 6.4).

6. Decide where it runs. Journeys belong in an environment where every service in the journey is real. Mock a dependency only when it's outside the journey's purpose.

How do you cover end to end API testing?

Not by combinations. Field-level variations belong in single-endpoint tests. For journeys, aim for:

1. One happy journey per use case. The store's use cases map to E2E-01 (order lifecycle), E2E-03 (catalogue maintenance) and so on.
2. One rejected-step journey. E2E-07 sends an invalid order (quantity: 0), checks the 400, then checks the order count didn't change before sending the corrected order. "Rejected requests leave nothing behind" is a journey-level property no single test can prove.
3. One recovery journey. E2E-08 uses the sandbox's ?error=500 and ?random_fail=true to check that a failed step has no side effects and a retry succeeds.
4. Journey-wide checks. Error rate across all calls, and a latency budget for the journey as a whole.

Common mistakes

• Only checking status codes. Four 2xx responses don't prove the order ended up in the right state. Read it back.
• Trusting a pass rate. A step that never ran isn't counted as failed. Check the list of steps that actually ran.
• Hard-coding IDs from a previous run. Carry them forward from the step that created them.
• Too many journeys. Each one is slow and brittle compared with a single-endpoint test. Keep the set small and meaningful.

End to end API testing in Shift-Left API

In Shift-Left API, a journey is a workflow: test blocks on a canvas, run in order on the server, step after step. Workflows are in every edition; the free edition holds up to 50 workflows of up to 10 blocks each, Start and Stop included.

1. Make four tests on the sandbox store: Create a user, Place an order (product aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa), Update the order (PATCH, body { "status": "processing" }) and Read the order back (expand=user,product).
2. Click Workflows, create one, and drag Start, the four tests from the Test Library, and Stop onto the canvas.
3. Wire green connectors for the order of the steps. On Create a user and Place an order, extract data.id as userId and orderId, and feed them forward with blue data connectors: userId into the order's user_id, orderId into the id of the last two steps.
4. On Read the order back, add checks: data.status equals processing, data.user.name equals the name step 1 sent, data.product.name equals Wireless Mouse.
5. Click Launch Workflow, then read the per-block report: every block should show PASSED. Click Check workflow if a block is missing; Workflow Doctor names steps that can't be reached, inputs no earlier step provides, and {{tokens}} nothing sets.

Two more ways to get journeys. Red failure connectors route a failed step to a different path, and workflow-level assertions check the whole run: error rate, throughput, and response time at p50, p95 or p99. And if your requirement documents describe use cases with ordered steps, Shift-Left API builds the workflow from them once every step has a test, and names the missing step when one doesn't (lesson 9.2 covers requirements). The integration test workflows feature page lists the block types.

Try it yourself

Build the four-step journey above as a workflow, wire userId and orderId with blue connectors, and launch it. Then change the PATCH body to { "status": "shipped" }, which the store doesn't allow, and see which block fails first.

Recap

• How to do end to end API testing: pick a journey from requirements, carry data forward, assert each step and read back the final state.
• API testing vs end to end testing: many fast single-endpoint tests catch most bugs; a few journeys catch the hand-off bugs between calls.
• How do you cover end to end API testing: one happy, one rejected-step and one recovery journey per use case, plus journey-wide checks.

For journeys that cross several services, read end-to-end API testing for microservices.

Next: lesson 6.7, what is API integration testing.