Saved requests carry the assertions that make a check reproducible. The api-testing skill runs your collection first against the mock (fast, safe) and then against the live API, and tells you what each result does and doesn't prove.

1. Ask Claude Code:

   ✦copy

   ›

   Add status-code and response-shape assertions to the animation movies requests, run my Movies API collection against the local mock, then run it against the live API using the Local environment. Report what each run establishes.

   Paste this into your agent

2. Confirm Claude uses postman collection run (with --use-mock "{{base_url}} mock:postman/mocks/movies-api" for the mock run and -e postman/environments/Local.environment.yaml for the live run) and reports assertion counts and the exit code for both runs.

3. Expect both runs to pass. Claude should also tell you what they don't establish — the mock replays your saved examples, so the mock run proves the collection and mock agree, not that the real API behaves that way, and neither run exercises the 404 path.

4. If any assertion fails, ask Claude Code to diagnose and fix it.

Each postman collection run against a workspace-linked project uploads its results to the workspace's run history.

One request with one input isn't much of a test. The datasets skill turns a file or database into queryable test input, so the same collection can run once per row — combined here with the api-testing skill to run the assertions across every row.

1. Ask Claude Code:

   ✦copy

   ›

   Create a CSV file with the ids 1 through 5, build a dataset and a saved view from it, and run my Movies API collection once per row so the "Get animated movie by ID" request uses each id. Tell me how many iterations ran and how many assertions passed.

   Paste this into your agent

2. Confirm Claude uses postman dataset create, adds the CSV as a source, and runs the collection with the dataset view as iteration data.

3. Check that the iteration count matches the number of rows in your CSV (5). The run repeats every request in the collection on each iteration, so with two requests expect 10 requests and 5 × the per-iteration assertion count in total.

4. The dataset engine writes working files such as data.db, meta.db and daemon.log. Keep them out of Git — Claude should add a .gitignore for them, and only the *.dataset.yaml manifest and the CSV should be tracked.

Functional tests pass with one caller; load testing shows how the API behaves with many. The performance-testing skill reuses your collection to generate concurrent traffic and checks latency and error thresholds. Run it against your local mock, not the public Movies API — a shared sample service isn't yours to stress.

Because your project is linked to your workspace, postman performance run runs the pushed copy of the collection, not your local files. The pushed copy from Part 2 still points at the live API, so push first; otherwise the test would send load to api.sampleapis.com instead of the mock. The test also runs in whole minutes, so the shortest duration is 1 minute.

1. Ask Claude Code:

   ✦copy

   ›

   My collection is linked to my workspace, so the performance test runs the pushed copy. First push my local changes with `postman workspace push`. Then run a performance test of my Movies API collection against the local mock using the local runner: 5 virtual users for 1 minute. Pass only if p95 latency is under 500 ms and the error rate is under 1%. Make sure no load reaches the live sampleapis.com API. Tell me what the result does and does not prove.

   Paste this into your agent

2. Confirm Claude pushes first, then runs postman performance run with --use-mock "{{base_url}} mock:postman/mocks/movies-api" and the --pass-if threshold flags, and reports requests per second, p95 latency, error rate, and a pass or fail verdict.

3. Sanity-check that the load really hit the mock: average response time should be a millisecond or so, not the hundreds of milliseconds a live API takes. If it's slow, stop the run and ask Claude to check which URL it's calling.

4. Read Claude's caveat. A mock baseline measures your collection and the load generator, not the real backend's capacity.