Version Control in Postman


Hey guys! We’ve been thinking long and hard on one of the most eagerly requested features for Postman, so we decided to go ahead and write an RFC to hear your thoughts on how we could solve your problems around version control. The linked doc also contains some conceptual mocks of how the experience would feel like. As always, feel free to leave your comments in the thread.

We’d also love to hear your thoughts in person, so if you feel you have a specific problem that we aren’t addressing with this RFC, you can schedule a quick call with us using the link below:


Provided I can make changes locally (for testing or just playing around) and not accidentally update the official (public facing) collection that our customers use. It shouldn’t matter in the least that I click Save because maybe I have some changes I want locally but not shared. “Updating” the collection (or even requests in the collection) should be an explicit action.

It would also be nice to see changes others have made so a merge tool would be a nice to have but not required. I don’t know that I’d really ever make a change to a public collection and not want all the changes to go so a simple file diff would be sufficient for me.

Integrating with our source control system would be a plus because we could version the collection with our source and then update the collection (via an API call) either at build time or release time. That would be the best of both worlds. Then I don’t really need versioning in Postman at all.

Converting team to personal workspace
removed this banner . It will no longer appear at the top of every page. #7

pinned globally #8


I think I’m with Kirk in most of his comments. This seems like a complex way to duplicate a lot of capability that already exists in other tools we are using. I’d be much happier if minor changes to a collection did not cause the resulting collection export file to drastically change (re-order, changes to internal IDs, etc.). It seems cleaning up the collection import/export process would be significantly easier and better address the customer needs.


In an ideal world, postman version control would integrate into the workflow of our code VCS. We mainly use postman for internal development and automated testing and we have the need to maintain multiple versions of the collections for multiple versions of our services and we need a way to keep this in sync so if I create a branch in git for a change, I can also easily branch my collection to make the associated changes in isolation. I think a way of allowing the source of collections etc to be specified in all your tooling and APIs would allow more natural integration with a whole host of other tools


Could not agree more! I would also prefer that the whole concept of import/export just went away. When I open code files in IntelliJ I don’t have to “import” them, and I don’t have “export” them to write changes to disk. I’d rather see the idea of a Postman project be more like opening a Word doc, where each project gets it own window, and changes to collections therein are autosaved.


Hey All! The wait is over.

Forking + Merging: A Conflict Resolution Solution now in Postman 6.7
Here’s a link to the detailed blog post-