Postman Pre-request Scripts vs Tests: A Decision Guide

Postman Pre-request Scripts vs Tests: A Decision Guide

The core decision when automating API workflows in Postman is determining where logic belongs: does it modify the request before it leaves the client, or does it verify what the server returned? Placing logic in the wrong tab can cause undefined variable errors, failed assertions, or collections that are hard to maintain.

Comparison at a Glance

Feature	Pre-request Scripts	Tests Tab
Execution Timing	Before the request is sent	After the response is received
Primary Purpose	Dynamic data generation & auth token calculation	Response validation & state persistence
Access to Response	None	Full (status code, body, headers)
Common Use Case	Generating HMAC signatures, timestamps	Validating JSON schema, status codes

Trade-offs to Consider

Pre-request Scripts run in a Node.js-based sandbox before the network call. This makes them ideal for tasks like calculating a cryptographic signature or generating a timestamp that must be sent with the request. However, complex JavaScript here can add noticeable latency, masking the API's actual response time and making performance comparisons harder.

The Tests Tab is the only place where you can inspect the full server response. Using Chai.js assertions, you can validate status codes, check response bodies, and extract data for subsequent calls. A frequent mistake is mixing setup logic with assertions, which conflates pass/fail results with configure/teardown flow.

Concrete Example: Dynamic Timestamp and Response ID Capture

Many APIs require a fresh timestamp in the request header, and return a transaction_id that downstream calls depend on.

// Pre-request Script: generate and forward a timestamp
const timestamp = new Date().toISOString();
pm.environment.set('current_time', timestamp);
console.log('Request prepared with timestamp: ' + timestamp);

// Tests Tab: validate the response and save the ID for later use
pm.test('Status code is 201', function () {
    pm.response.to.have.status(201);
});

pm.test('Response contains transaction_id', function () {
    const json = pm.response.json();
    pm.expect(json).to.have.property('transaction_id');
    pm.environment.set('last_transaction_id', json.transaction_id);
});

Verification and Practical Checks

1. Open the Postman Console (Ctrl+Alt+C on Windows, Cmd+Opt+M on macOS) and confirm the console.log appears before the network request in the timeline.
2. Run the request and switch to the Test Results tab in the response pane. Both assertions should show a green PASS.
3. Click the Environment Quick Look (eye icon) and verify that current_time and last_transaction_id reflect the generated and captured values.

Limitations and Risks

• Scripts cannot access the local file system (e.g., fs.readFile is unavailable). For data-driven testing, import JSON or CSV files via the Collection Runner.
• Never hardcode API keys or secrets directly in script tabs. Use Environment Variables with the type set to Secret so the UI masks them.
• Heavy computation or loops in Pre-request Scripts can delay request transmission, skewing performance measurements.

Since scripts execute entirely within Postman's client and do not modify the API server, rollback only involves cleaning up the Postman environment and clearing the script tabs to restore static request behavior.