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.


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.

1 Like

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-

Sorry, but that is not what most people need. From the looks of it, you’ve implemented version control in the application… that is exactly the wrong way to do this.

This isn’t hard. You already have the collections serialised… just make postman point at a file location and watch that. If the collections change, update the file and vice versa.

Leave the forking, merging, etc to the version control system… i.e. the thing that was designed to do that.


@cgrealy I mostly agree with you. The only part that is unpleasant is working with JSON files (reviewing, merging / fixing conflicts). This is really a mess.


I want my collection(s) inside my repo. I want to check them in and out based on what branch I’m on. I want Postman to know when I change branches. I want my requests and ultimately, the tests, to pass/fail based on the code that’s in the repo. That allows me to know what/why/when something broke.

Postman should adopt OpenAPI V3 as its native data format. Then the versioned openapi doc goes into version control. Sounds radical, but …

OAS V3 currently supports most of what Postman needs, except testing, but permits custom elements. This means Postman would need to define a set of x-postman- elements where OAS has no analogue of Postman’s JSON data format.

Of course OAS will need to address test definitions eventually. Will it be Postman or SmartBear that takes the initiative here? It looks to me like Postman is far closer to a working system.

1 Like