Option C: Separate workspaces for dev, staging, and productionĬons: Organizational overhead of managing multiple Postman workspacesĪny advice on what you guys might be doing in your organizations would be helpful Any updates to the API need to be sent to all 3 collections. Pros: Collection variables keep API keys separate from other APIs, no giant shared list of variablesĬons: Collection management gets harder now our workspace has 3 times as many collections to navigate through. Option B: One collection per environment: So I have a ‘billing-api-dev’ Collection, ‘billing-api-staging’ Collection, etc. Pros: Uses environment feature of Postman, can use one collection per real APIĬons: All 12+ differrent integrations and APIs all share one giant environment variable now I need to manage a messy list of 100+ variables. Option A: dev, staging, and production environment. So my question is: How do I best organize this structure? I see a few different options: Which seems to defeat the purpose of having the environment switching feature of Postman. 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.
0 Comments
Leave a Reply. |