Exporting without saved response IDs and postman collection ID

[gabipetrovay]

1. Postman Version: 4.10.5
2. App (Chrome app or Mac app): Chrome app (Chrome 54.0.2807.0)
3. OS details: OS X / x86-64
4. Is the Interceptor on and enabled in the app: yes
5. Did you encounter this recently, or has this bug always been there: yes
6. Expected behaviour: stable saved response ID or having the possibility not to export the IDs of the saved responses at all.
7. Console logs (http://blog.getpostman.com/2014/01/27/enabling-chrome-developer-tools-inside-postman/ for the Chrome App, View->Toggle Dev Tools for the Mac app): N/A
8. Screenshots (if applicable): N/A

Importing and exporting a collection will export also the following non-stable values:

• _postman_id
• for each saved response an id

For every import-export these values change and therefore this is not source versioning friendly. Hence a Postman collection cleanup step is necessary before committing the exported collection.

It would be nice if the non-stable internal IDs would either:

• not be exported
• removed from the export using an option during the export process

[macejiko]

Any progress on this? Really blocks our team from using postman..

[sberczuk]

Our workflow is to keep the canonical versions of collections in Git, and push then to the cloud in CI, using the IDs as keys. And the Postman Editor is the nicest way to edit collections. So being able to import, edit, export without having to manually revert the ID change would be helpful. So for us "keeping the ID" is useful. Deleting it is not.

[jackieta1]

This is huge issue for us too. Please prioritize this.

[grimsa]

VCS-friendliness was made worse in 7.23 due to the script ID uniqueness fix. See #4802

[murven]

Starting from version 7.23, Postman does not seem to be a viable option for our team due to the replacement of the IDs in hundreds of test cases. We are looking for ways to workaround this issue or moving away from Postman altogether.

[manoelagonzaga]

Any updates about this issue? The GUID changes is difficulting a lot the evaluation of real tests changes.

[luto65]

I use SMART Json Editor in order to modify postman collections.
Perhaps one could use also Atom or Eclipse.

[jgalvacky-bt]

+1 Any update on this? This has become quite the pain point while using any versioning tools.

[zoranbgd]

+1 Is this going to be implemented soon? We are considering other options - editing JSON in editor is not good idea if you have a large collection.

[eraymond-bt]

Hoping you can please fix this ASAP. Running a diff across versions in source control is so painful with a large collection now. The diff is filled with hundreds of "id" mismatches that I don't care about, making the changes I do care about much harder to see.

[ManiacDC]

@eraymond-bt

You can fix BC using this, then toggle minor differences as needed:

[eraymond-bt]

Thanks @ManiacDC. I'll give that workaround a try. It may work for me on my machine, but the file I commit will still have the "id" changes, which could impact my teammates if they do not have this BC configuration, or if they're using another diff tool. Thank you for the suggestion!

[ManiacDC]

@eraymond-bt I work around this by keeping two copies of the file. I import/export my file NOT in the working copy, then I use BC to move the changes to the file in my WC. I move only the IMPORTANT changes. Then I'm not cluttering my commit with IDs. If you want to sync up the two files, you can just copy the file from your WC and overwrite the other copy, or turn minor differences back on and copy all the minor differences over to the other copy.

[zoranbgd]

@ManiacDC There are many workarounds, but proper solution is to remove IDs when collection is exported from Postman. This can be optional (checkbox, for example) on export screen.

[ManiacDC]

@zoranbgd of course? That's why my post above is a workaround. It's a ton of work that wouldn't be needed if we simply could export without IDs.

[mairo744]

+1

[RanceJen]

+one

[mccannt]

Thanks, everyone for the input and upvoting, it really helps us understand the needs of our userbase.
With that being said, we should have something out very shortly to address this. :)

[arlemi]

Hey everyone! We've just released Postman 7.36.1 that now strips all IDs from the collection exports. You can update your app or get the latest version from the downloads page.

Thanks for your patience with this issue and let us know if you have any feedback. 🙏

[lbenedetto]

Looks like the API is still serving up _postman_id

curl -s -H "X-Api-Key: ${POSTMAN_API_KEY}" https://api.getpostman.com/collections/${COLLECTION_ID}

Will the API be changed as well? Or is there a v2 I need to switch to?

[zoranbgd]

Thank you @arlemi, this really means a lot.

[arlemi]

@lbenedetto Calling that endpoint on the same collection will always give you the same IDs, though seeing your workflow
I understand this doesn't solve it for you. Let me ask and see if there are plans and/or if we should create a separate issue for it.

[micaelboucard]

Yes, thank you!
Works like a beauty!

[arlemi]

@lbenedetto The API will be changed as well, I've created this issue so it can be tracked separately to this one which is now resolved: #9375 🙂

[chai2]

Thanks a lot, @arlemi for the announcement. Just tried and works like a charm!!

[VV-55]

This update looks useful in version control in postman. But where could i find export option in version 8.0 postman?

[mccannt]

@VV-55 You can find it by opening up the collection in a tab (clicking on the collection name in the left nav) and then clicking on the ellipsis and then Export.

[Thommynator]

I'm wondering if I'm doing something wrong.
My Postman version is v8.0.6 and I'm exporting to a v2.1 Collection.
I still have the same issue that all the script id's are different after the export.

Do I need to change a setting or something?
@arlemi do you have a hint? :)

[arlemi]

@Thommynator I've tried on the latest v8, and Postman Web, but I'm not seeing the IDs being exported... Is that an old collection that you're trying to export? And do you have this issue with any collection or just this one?

[Thommynator]

What I did:

• Create a new collection
• Export collection
• Import collection (replacing the existing one)
• Export collection to a different file
• Compare the two exported files

For me the _postman_id changes after every export.

"info": {
    "_postman_id": "34eee1be-296a-407a-884c-9a69ba1c5bd1",    <<< this one
    "name": "New Collection",
    "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
}

Additionally, all the requests which are using a "Pre-request Script" and/or a "Test Script" had changing ids, too.

"event": [
  {
    "listen": "test",
    "script": {
      "id": "f4e200b7-8c80-41c9-807e-ed5efc52a377",  <<< this one
      "exec": [
        ""
      ],
      "type": "text/javascript"
    }
  },
  {
    "listen": "prerequest",
    "script": {
      "id": "b3bbfa55-d48c-41c6-b944-844765325675", <<< this one
      "exec": [
        ""
      ],
      "type": "text/javascript"
    }
  }
]

But now I found out that this only happens for already existing requests. New requests will not have this id anymore.
That's cool! :) What's the best way to do it for all the existing requests as well? Should I remove all the ids from the JSON (manually) or is there an easier way?

[arlemi]

So the _postman_id will keep being updated whenever you import a collection, Postman considers that this is a new collection and therefore assigns a new id to it. If you keep on exporting the same collection, that id shouldn't change.

Have you tried if duplicating the requests was getting rid of the script ids? Otherwise recreating them, or removing the ids manually are the only things I can think of. 🙁

[jgalvacky-bt]

On the latest Postman version (v8.2.2) the Collection Variables are generating new ID's every time with each export of the collection. Similar problem to what was resolved with this current issue. This type of bug keeps sneaking back in.

• import collection (that contains collection level variables)
• export collection
• the exported collection variables all have new ID's assigned to them (not expecting this to happen)

Anyone else seeing this happen? New Bug Issue needed?

[arlemi]

@jgalvacky-bt Thank you for reporting, we're looking into it!

[Lampei]

@arlemi so how do we go about keeping the ids in collections? I need to run specific folders (via newman) and if they have duplicated names, then the only way to do this is using the "id" of the folder. If these are being removed each time I export from Postman UI, then I would have to keep adding those ids back in again.

[helloint]

This is my experience:
I have one existing collection in maintenance. Usually I update the collection via Postman app. But sometimes I need to do batch operation so I will export the collection to a JSON file and use text editor to finish the work, and then Import again. I will also have a copy in my Version Control so Jenkins will check it out to do automation works.
So, after the Export -> Import -> Export I noticed the info._postman_id will change, and I can't find a way to avoid this, even I remove the _postman_id before Import.
I tried the App with Version 9.14.14 and also the web app, same results.
Is this the issue @arlemi is looking into? If yes, any updates?

[Smitzel]

Any updates? This goes on for years... Must not so hard to fix permanently

[sprive]

This is still an issue on Postman 10.12.0.

1. I imported an existing collection. It has existing _postman_id IDs.
2. . When I export that collection (making no changes to it), it now has a different set of IDs.
3. (Probably user-specific IDs, yeah?)
4. Now... I can manually scrub these from PRs...

Can we get a documentation word on what the argument was to include personal IDs in an export?
ie What value gets lost if we delete them? In other applications, when we export something, we completely expect some metadata to be excluded from the export instance.