Real usage is a sequence — create a resource, get an id, then use it. These tests exercise the API the way it's actually used.
Chain Create then Read with a Variable
Testing each request in a vacuum misses the bugs that only appear between them — an id returned in the wrong field, a format the next call can't consume. Capturing a value from one response and feeding it to the next tests the real workflow.
In Agent Mode, run a prompt like:
On the POST request, add a post-response test that reads the id from the response and saves it to a collection variable called movieId. Then, on the "GET /movies/animation/:id" request, keep
:idin the URL and set the value of theidpath variable to {{movieId}} so it fetches the record the POST returned.
Keeping :id in the URL and pointing the path variable value at {{movieId}} is the idiomatic Postman pattern — the URL stays readable as /movies/animation/:id while the value resolves at send time. Check the request's Path Variables section to confirm id has a value of {{movieId}}.
The sandbox won't persist the created record, so the follow-up GET won't find it — but the chaining mechanics are the transferable skill. Point the suite at a persistent API and the same workflow verifies end to end.
See it for yourself: Send the POST, then open GET /movies/animation/:id, confirm its id path variable value is {{movieId}}, and send it — watch the value resolve to the id the POST returned. The sandbox won't have persisted the record, so the follow-up GET won't find it — but you can see the value flow from one request into the next in the response pane.
Add a Response-Time Budget
An endpoint can be perfectly correct and still be a bad experience. Performance is part of the contract — a search that takes four seconds is a defect even when every field is right. A response-time assertion turns "feels slow" into a number the suite enforces.
In Agent Mode, run a prompt like:
Add a post-response test to every GET request that asserts the response time is under 800 milliseconds.
Set the threshold to a budget your users would actually accept, then treat a breach as a signal to investigate — not as noise to raise the limit past.
See it for yourself: Send a GET request and open the Test Results tab — the response-time test should show a green PASS, and you can read the actual timing next to the status in the response pane.