- Installation and updates
- Sending your first request
- Navigating Postman
- New button
- Creating the first collection
- Postman account
- Keyboard Shortcuts
- Troubleshooting In-app Issues
- Authorizing requests
- Working with Tabs
- Visualize API responses
- Validating Requests Against Schema
- Generate code snippets
- Using GraphQL
- Making SOAP requests
- Capturing HTTP requests
- Debugging and logs
- Troubleshooting API requests
- Intro to collections
- Creating collections
- Sharing collections
- Commenting on collections
- Managing collections
- Version Control for Collections
- Using Markdown for descriptions
- Data formats
- Working with OpenAPI
- Collaborating in Postman
- Roles and permissions
- Managing your team
- Requesting access
- Team Settings
- Audit logs
- Intro to scripts
- Pre-request scripts
- Test scripts
- Test examples
- Branching and looping
- Postman Sandbox
- Postman Sandbox API reference
- Intro to collection runs
- Starting a collection run
- Using environments in collection runs
- Building workflows
- Running multiple iterations
- Sharing a collection run
- Working with data files
- Debugging a collection run
- Command line integration with Newman
- Integration with Jenkins
- Integration with Travis CI
- Newman with Docker
- Documenting your API
- Authoring your documentation
- Publishing your docs
- Viewing documentation
- Custom documentation domains
- Intro to mock servers
- Setting up a mock server
- Mocking with examples
- Mocking with the Postman API
- Matching algorithm
- Intro to Monitoring
- Setting up a monitor
- Viewing monitor results
- Monitoring APIs and websites
- Set up integrations to receive alerts
- Running Postman monitors using static IPs
- Troubleshooting monitors
- FAQs for monitors
- Intro to Workspaces
- Creating Workspaces
- Using Workspaces
- Managing Workspaces
- Viewing changelogs and restoring collections
- The API Workflow
- Managing and Sharing APIs
- Versioning APIs
- Viewing and analyzing APIs
- Validating Elements Against Schema
- Customizing Postman
- Find and Replace
- Purchasing Postman
- Intro to SSO
- Configuring SSO for a team
- Logging in to an SSO team
- Configuring Microsoft AD FS with Postman SSO
- Setting a custom SAML in Azure AD
- Setting up custom SAML in Duo
- Setting up custom SAML in GSuite
- Setting up custom SAML in Okta
- Setting up custom SAML in Onelogin
- Setting up custom SAML in Ping Identity
- Intro to Integrations
- Custom Webhooks
- Microsoft Flow
- Microsoft Teams
- Publishing API documentation
Starting a collection run
Collections are groups of requests that can be run together as a series of requests, against a corresponding environment.
You can use scripts to build integration test suites, pass data between API requests, and build workflows that mirror your actual use case of APIs.
The collection runner allows for customizing the execution of requests in the following ways:
- Order of execution: The requests execute in the order they appear on the Run order pane of the collection runner. The execution can be reordered by dragging and dropping.
- Selective execution: Requests can be prevented from executing by disabling them using the preceeding check boxes in the Run order pane of the collection runner.
This topic describes how to configure collection run parameters for:
- Collection or folder
- Log responses
- Persist variables
- Run collection without using stored cookies
- Save cookies after collection run
The collection or folder you want to run.
When you run a collection, all requests in the collection are sent in the order they appear in the main app. As a result each folder is run, and each request inside the folder, is sequentially executed. When you select a folder, only that folder is executed and only requests inside the folder are sent. You can, however, change the order to more closely mirror your workflow when you use the
postman.setNextRequest() method. You will also be able to use the collection runner for form-data request and binary file bodies containing files.
To learn more about how to build a workflow, see Building workflows.
The environment to use when a collection runs.
To learn how to use environments in collection runs, see Using environments in collection runs.
The number of times the collection will run.
Sending different data in each iteration and setting a higher iteration counts usually ensures the stability of your APIs.
To learn how to run multiple iterations, see Running multiple iterations.
The interval (in milliseconds) between each request in a collection run.
Limits response logging when the collection runs.
By default, all responses are logged for debugging purposes. For large collections, you can change this setting to improve performance.
Here's more detail about default logging:
- For all requests, responses for all requests will be logged.
- For failed requests, only responses for requests with at least one failing test will be logged.
- For no requests, no responses will be logged.
To learn how to debug collection requests, see Debugging a collection run.
Supplies a data file to use for the collection run.
To learn more about how to use a date file for a collection run, see Working with data files.
By default, any environment changes in the collection runner are not reflected in the request builder. Enabling this option saves the values of the variables at the end of the run, overwriting previous values.
To learn more about Keep variable values in a collection run, see Using environments in collection runs.
A request from the collection may require cookies to run. Collection runner can allow/prevent the request from accessing the cookie by the Run collection without using stored cookies option. Enabling this allows collection runs without using cookies stored in the cookie manager.
A request in the collection may create/update cookies during execution. The Collection runner provides an option to save the cookie to the cookie manager, overwriting any existing cookie. Enabling this saves the cookies for the session to the cookie manager.
For more information about collections runs, see: