Session 6: API Testing | Postman | API Chaining

Main topic: API chaining in Postman (Session 6)

This session explains API chaining: the response from one API request becomes input (or part of the request) for the next API request.

A key requirement is that some data from the first response must be extracted and stored—typically an ID—and then reused in subsequent requests.

It also connects this idea to earlier Postman concepts:

• Using variables at different scopes (global, environment, collection, local)
• Using scripts to set and access variables

---

Core concepts + implementation approach (Postman)

1. Variable setup from response

After a request completes, use the Test tab script to parse the response and extract fields (commonly id).

Use:

• pm.response.json() / JSON parsing to capture the response body
• JSONPath-like access such as jsonData.id
• pm.environment.set("VAR_NAME", value) to store extracted values

2. Using stored values in later requests

In subsequent requests (URL params or request bodies), replace hardcoded values with environment variables using:

• {{variableName}} syntax

3. Dependency execution order

Chained requests must run in sequence:

• Create → Get (using created ID) → Update → Delete (using the same ID)

---

Example 1: Chaining with a local “Student API” (json-server + Postman collection)

Workflow built in Postman

• POST / create student
• GET / get single student (uses the student ID from the POST response)
• DELETE / delete student (uses the same student ID)

Implementation details

Test tab (POST request):

• Parse response body
• Extract generated id
• Store it in an environment variable like ID

GET and DELETE requests:

• Replace hardcoded IDs with {{ID}}

Lesson from debugging

Even if requests run successfully, tests/validations can fail (e.g., assertions expecting the wrong values/status). They adjusted/removed/handled validation logic so the collection passed reliably.

---

Example 2: Chaining with a real remote API (GoREST) including authentication + dynamic data

Remote API prerequisites

GoREST endpoints require a Bearer token. They walk through obtaining a token after signup/login.

Important: the token must be included in the Authorization header for methods like:

• POST / PUT / PATCH / DELETE

Requests created

• Create user (POST)
• Get user (GET by ID)
• Update user (PUT/PATCH)
• Delete user (DELETE)

Authentication setup improvement

Instead of adding the token to every request, they set it at the collection level:

• Postman Authorization → Bearer Token
• Requests inherit via inherit auth from parent/collection

---

Dynamic request body generation (repeatable tests)

Because GoREST rejects duplicate email addresses, the session demonstrates generating random data at runtime.

Pre-request script (for POST/PUT)

• Generate random strings using JavaScript (e.g., Math.random().toString(36).substring(...))
• Build:
  • random email
  • random name (and sometimes other fields)

Store generated values in environment variables

• pm.environment.set("email_env", generatedEmail)
• pm.environment.set("name_env", generatedName)

Use them in the request body

• Use {{email_env}}, {{name_env}} in JSON body fields

---

Extracting and reusing ID from the remote API

Test tab (POST request)

• Parse response JSON
• Extract id
• Store it in user_id_env (environment variable)

GET/PUT/DELETE requests

• Use the extracted ID in the URL:
  • .../users/{{user_id_env}}

---

Validation/testing (ensuring chaining correctness)

For the GET user request, they add tests to compare returned fields with the values originally generated:

• id matches stored user_id_env
• returned name matches name_env
• returned email matches email_env

They use:

• pm.test(...)
• pm.expect(...)
• pm.response.json() to read response fields

---

Best practice: deleting runtime variables after collection runs

After the flow completes (after delete), they unset environment variables to prevent clutter and free memory:

• pm.environment.unset("user_id_env")
• pm.environment.unset("email_env")
• pm.environment.unset("name_env")

---

Final deliverable mentioned

The instructor will share a document with step-by-step scripts and request setup for:

1. Student API chaining (local)
2. GoREST API chaining (remote, with Bearer token, dynamic data, extraction, validation, cleanup)

---

Main speakers / sources

• Primary speaker: the course instructor (teaching Postman API testing; examples focused on “Session 6: API Testing | Postman | API Chaining”).
• API sources used in examples:
  • Local: “Student API” served via json-server (students.json)
  • Remote: GoREST (gorest.co.in) sample APIs (Bearer token authentication)