Adding Delay Between Requests in Postman and Newman

When running a sequence of API requests, you may need a controlled delay between calls—for example, to simulate pacing, wait for an asynchronous dependency, or avoid overwhelming a test environment.

This article documented three approaches available in the Postman tooling used at the time.

Collection Runner Delay

The Collection Runner allowed a delay value, in milliseconds, to be applied between requests for the collection run. This was useful when every request should use the same pacing.

Newman Command-Line Delay

Newman, Postman's command-line collection runner, supported a request-delay option:

newman run <collection-file-source> --delay-request <milliseconds>

This provided a repeatable way to apply collection-wide delay in automated or command-line test execution.

Request-Level Scripting

The original workflow also explored setTimeout in pre-request or test scripts to introduce request-specific pauses. That gave individual requests different timing behavior.

Version context: Postman's scripting sandbox and collection-runner behavior have changed over time. Do not assume that a historical setTimeout pattern blocks request execution in the same way in current Postman versions. For current tests, verify the supported execution semantics and prefer explicit runner controls when you need deterministic pacing.

Design Consideration

A fixed delay is not the same as waiting for a system condition. If a test depends on an asynchronous operation completing, polling for a bounded condition can be more reliable than sleeping for an arbitrary amount of time.

Takeaway

Use collection-level delay for consistent pacing, runner-level options for automation, and request-specific logic only when the test genuinely needs different timing behavior. Keep timing controls explicit so test duration and behavior remain understandable.