Best Practices for managing collections and multiple environments

šŸŒ± Just Getting Started
,
1

Hello! I am working on trying to formalize my companyā€™s Postman collection setup, and Iā€™m struggling with how to best set up collection variables vs environment variables in a way that makes sense.

  • Weā€™d like to be able to interact with multiple environments; test, staging, and production. I realize I can choose the Environment in the top right, and thatā€™s exactly what weā€™re doing today.
  • We have several different microservices that have separate, distinct APIs: For example, a Slack bot, a Shipping API, an Invoice/Billing API, an Inventory Management API, handful of APIs that integrate with 3rd party CMSs, etc.

From my point of view, it doesnā€™t make sense for the Billing API to be able to see and access the URL or API token for the Shipping API, so that makes me think I should put the api token as a collection variable, as opposed to an environment variable. However, we have API keys for dev, staging, and production, and so if I put it as a collection variable, then I would need multiple collections, one for each environment. Which seems to defeat the purpose of having the environment switching feature of Postman.

So my question is: How do I best organize this structure? I see a few different options:

Option A: dev, staging, and production environment. Each one has the following variables:
billing-api-key
shipping-api-key
etc.

Pros: Uses environment feature of Postman, can use one collection per real API
Cons: All 12+ differrent integrations and APIs all share one giant environment variable; now I need to manage a messy list of 100+ variables.

Option B: One collection per environment: So I have a ā€˜billing-api-devā€™ Collection, ā€˜billing-api-stagingā€™ Collection, etc.

Pros: Collection variables keep API keys separate from other APIs, no giant shared list of variables
Cons: Collection management gets harder; now our workspace has 3 times as many collections to navigate through. Any updates to the API need to be sent to all 3 collections.

Option C: Separate workspaces for dev, staging, and production
Pros: Get one simple collection list
Cons: Organizational overhead of managing multiple Postman workspaces

Any advice on what you guys might be doing in your organizations would be helpful :slight_smile:

Thanks,
Matt

3 Likes
2

I know this is a bit older, but I wanted to share that we are in the same boat with standardizing our Postman collections as well. We do not have our API keys stored in the ā€˜Environmentsā€™, because we donā€™t have (nor should we) a master API key that works across all of our APIs.

But defining API keys at the collection level would require us to create multiple variable setsā€¦ say if we have qa, staging, production, weā€™d have to do (api_user_qa/api_pass_qa, api_user_staging/api_pass_staging), which seems odd.

Creating multiple collections for an API, one for each environment, also doesnā€™t seem like a good way either.

If we come up with something, Iā€™ll share some ideas here.

1 Like
3

We are in the same boat. Any suggestions/ideas from the Postman team or other?

1 Like
4

Hi there,
This is a great topic and perhaps one that we may need to create some formal content / best practice blogs on.

In the meantime check out this blog post which talks about organizing collections environments and workspaces :

If you ever plan to build out any public workspaces check out this blog post from @jetison as well to understand how you can go about setting up those

5

Question 1: Requests are are organized in collections/folders why environments are not?

  • if you could put multiple environments in a ā€œfolderā€ it could derive from its parent.
  • You could have a folder for one device and have multiple environments, one for each login.
  • Or each techuser could have a folder and you could have one environment per server.

Question 2: It would be cool to restrict a collection to a set of environments. We have really different projects (=collection) in parallel. Each project belongs to its own servers and different technical users. So the amount of environments is a permutation of the collection (=project), the server and the tech user.

  • If a collection is restricted to a set of environments you cannot pick the wrong environment.
  • If a collections point to one or more environments it could be exported together with this collection.

If you think the both points above together a collection could point to an environments folder to restrict the choice of environments with one click.

2 Likes