Postman Release 6.2: Postman Teams for Free Users, and Session Variables Enhance Teamwork


Update, July 2020: A lot has happened since this release. Check out our 2020 post about Postman’s momentous return to the web.


 

We’re excited to announce a significant release to the Postman app—version 6.2. In this version we’ve made Postman Teams available to free users, to help make API development and collaboration even easier. Previously, Postman Teams were only available with Postman’s paid plans; now, all users can invite their colleagues to a Postman team. Postman 6.2 also strengthens collaboration for all teams with the addition of sessions & session variables—which provide additional security and flexibility when collaborating on shared collections.

Teams for Free Postman Users

Free users can now create a Postman Team, and invite as many colleagues as they’d like, to collaborate within Postman on their API development. Postman Teams and Team Workspaces are used extensively by Postman Pro & Enterprise users, and can now be used by free Postman users in quantities targeted for small projects.

To get started, free Postman users can create a team workspaces, and invite colleagues to that workspace. Once their colleagues accept the invitation, they’re added to both the team workspace and the free team, and can begin collaborating immediately. 

Workspaces allow Postman users to organize their API development into distinct spaces for organized API development with Postman elements (such as collections, mocks, and monitors).

Changes made within a team workspace are synced in real time, allowing developers to work together within Postman—much as editors might collaborate within a single Google Doc. Postman teams can collaborate seamlessly, knowing that everyone is working off of the most up-to-date version of their team’s collections.

All Postman users can create an unlimited number of Personal or Team Workspaces, and invite an unlimited number of team members to their Postman team.

Postman Pro & Enterprise teams can add as many Postman elements (requests, collections, environments, etc.) as they wish to their Workspaces. Free Postman teams are limited to 25 API requests per team, which can be shared across multiple team workspaces. Free Postman teams that exceed 25 API requests will see the oldest request (or the collection containing the oldest request) archived.

You can read more about free teams in our Free Teams FAQ.

Sessions for All Postman Users

In addition, Postman 6.2 includes a new feature called sessions, which allows teams to work more effectively through the addition of session-specific collection, environment, and global variables.

A good way to think of a session is as an additional layer within the app, stored locally, and unique to each individual Postman user. The session contains variable values that the developer wants to use but might not want to be synced to the server or shared with the team, such as username/password combinations or other sensitive information. Users can manipulate variable values while working on collections, and those changes are captured only in their individual sessions.

Since session variable values are not synced to the cloud, sessions allow developers to work comfortably with sensitive information, knowing it will stay local to their Postman instance. This gives users more flexibility in working with APIs in Postman, and reduces security concerns.

Sessions are implemented for all Postman users in 6.2, and are available across all Postman plans.

You can read more about sessions in our Sessions FAQ.

What do you think about this topic? Tell us in a comment below.

Comment

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.

3 thoughts on “Postman Release 6.2: Postman Teams for Free Users, and Session Variables Enhance Teamwork

    i want to read the csv file row wise how to do?

    Hi,
    My name is Brian Yeon. I am new to Postman.
    What should I enter for the eats_store_id (location UUID) for testing? I am guessing is is kind of location information. Dev doc is asking client_id, client_secret, and eats_store_id (location UUID). I have client_id and client_secret but I have no idea what to put for UUID. Suppose the developer does not own any restaurant, then what kind of value the developer should enter?