Best Practices for managing collections and multiple environments

New to APIs/Postman
,
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

2 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.

3

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

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.