Postman simplifies and brings together the mechanics of API collaboration to help you interactively plan, develop, publish, and maintain APIs within your team, company, and across the planet. In this topic, you'll learn about the types of teams and workflows for internal and external API collaboration in Postman.
You can collaborate in Postman internally within a single team, multiple teams, or an entire company. Postman also enables you to collaborate externally, with one or more partner companies. How you decide to set up your teams and collaboration levels will depend on your API strategy.
If you're new to Postman, try the no-cost entry to collaboration features with a free team of up to three members. To collaborate with more team members, features, and increased usage limits, you can upgrade to a Basic, Professional, or Enterprise plan. When you're ready to scale your work, select Upgrade in the upper-right corner.
To define your API strategy, it's important to do the following:
Learn more about function-based role types and how to set them up in Postman. You can arrange users into groups that reflect your organizational structure. Users can request Editor access to workspaces and elements they initially can only view or try to access from a shared link, enabling you to assess and scale teams as needed.
Postman enables you to collaborate in units from single teams to multiple companies in different phases of the API development lifecycle:
To begin API development, an engineering team can create a prototype collection in a private workspace with requests to represent the API to be built.
To prepare the collection for further iterations, the engineering team can do the following:
The team can then fork the collection into another private workspace and invite potential consumers to provide feedback.
When interacting with a prototype collection, the consumer team can do the following:
The changes the consumer team makes can be pulled back by the engineering team to update the original collection and iterate on the API. The team can then share changes to the collections using workspace updates.
Engineers use the collection as a reference to implement the API in code. As they write code, they continuously test and debug the API to ensure the API is working as expected.
Consumers can simultaneously integrate the API into their front-end application or their own service using mock servers.
QA teams can fork the collection to their testing workspace and write scripts for functional, regression, and end-to-end testing. Next, they can validate tests manually by sending an individual request or, once the testing collection is set up, by running the tests in the Collection Runner. Then, you can check the run report for failures.
DevOps teams can select collections and environments to be run as a part of the build. They can connect Postman to their own API workflows using integrations with popular third-party solutions. Integrations enable automatic sharing of data between Postman and the other tools that DevOps relies on for API development, such as GitHub, Slack, CircleCI, Amazon API Gateway, and New Relic.
For publicly accessible APIs, DevOps teams can schedule runs in sync with nightly builds to continuously ensure quality over a period of time.
Partner Workspaces in Postman allow for direct collaboration with external partners, facilitating API consumption and joint API project work. This type of workspace helps to establish a central source of truth and integrates partner projects into the Postman team for efficient partnerships.
With multi-partner mode, managing multiple workspaces for different partners becomes easier, enabling collaboration with several partners within the same workspace. This mode allows for sharing and updating Postman Collections with multiple partners, inviting partners to test APIs at a moment's notice, showcasing real-world workflows, and maintaining a reference workspace for API endpoints and documentation.
Last modified: 2024/09/04