Download EXCLUSIVE Postman Collection
Basa Uram
Hi
I have collections imported into my Postman. Now I have created a new Collection and created a folder under it. I now would want to move the existing collection into this newly created folder. Is that even possible in Postman?
I have been looking for something like this myself @praveendvd! I made this public workspace for a talk I gave at a conference recently, and wanted to move all of the individual collections into one overarching collection in a different workspace. So this may be just what I need!
Same with me, same version, same result. The backup files in the .\Users\xyz\Postman directory seem to be taken during updates of the local software. The real collections are in the IndexDB subdirectory but only while Postman is running and they are not usable (DB files). The question is, where is the real current collection data?
I think I found it, and this is no good news then:
There is a directory: *c:\Users\haste1960\AppData\Roaming\Postman\Partitions\ef0a69d0-0e50-494c-9f27-d8fac8d93706\IndexedDB* in my example case that contains a persisted database file structure. It sames as if, during Postman run time (and probably without haing a workspace configured, that at least is my case) these files are opened and represents the collections the user interface allows to work on. These runtime db files are maintained in the Postman\IndexDB subdirectory and, probably, persisted back to the above directory during shutdown. But, these files are not usable from outside as they seem to be database files.
My assumption is, that Postman discarded the Export function for non-workspace usage and therefore we are not able to export anymore all at once but only collection by collection
I agree, that this is bad, when we can not export data in new postman versions. But is marketing thing from them to force users to use online version.
Anyway, you can download version 9 here, where is export still available.
_pro/managing_postman_pro/migrating_to_v7/#download-latest-postman-v6-app
But you should disable autoupdates then.
The second after being logged in, I noticed that the collections I had disappeared.
First I thought that there were on an other account (pro vs personal gMail) so I proceeded to login to the other account.
And then again, no collections. All have disappeared !!
I believe you have tried copying data within the file: /snap/postman/80/.config/Postman/IndexedDB/file__0.indexeddb.leveldb/ to Canary location /.config/PostmanCanary/IndexedDB/. If not yet, please try the same and check if any data locally stored can be recovered.
I'm importing a swagger specification file into postman to create a collection, at this point, works as expected and the collection is generated with all requests & sub-folders, fine!!. But when the api is updated, I need update the postman to update all requests based on the new specification. I can't find a action like "update" or something else. I'm trying import the new specification into postman and he say:
The tool will combine new and old collection, when conflict, it will use saved in postman. The tool can detect update in query parameter, but not post body. It will keep all your collection and test cases.
There is no straightforward solution. There also probably won't be one for quite some time - the devs said it is hard to correlate old Postman requests in a collection with new requests generated from incoming Swagger file (or any other source of updates, for that matter).
I made myself a simple helper for step 3. It is fine if you are just adding more stuff to the collection (my case), but can't remove anything. If anyone has a more versatile solution, please, post it - I would gladly use it instead.
I've needed this for a while too, and still does not seem to be there (updating a collection from swagger). However, I did export a collection that had some new endpoints to save what I had in case the new import clobbered my existing collection. Then imported the new swagger in the same workspace. It automatically imported into a new collection with " Copy" appended. From there, I could drag the new endpoint(s) to my current collection.This does MOVE the endpoint(s), but I don't really need to keep the copy so I deleted the entire copied collection.
One interesting observation is that if a collection was previously shared with multiple workspaces you can still add new requests, and folders, and they will be synced. The core functionality is still present in the current version.
I have a postman collection with 3 requests in it. When I click on "Run Collection" normally all 3 requests are sent. Yesterday I figured out that only the first one is triggered, the others are ignored. I have cloned the collection, I have re-created the collection, I've updated postman... don't know what else to do..I am on version 9.4.1 - maybe someone has an idea, thanks.
Postman is a collaboration platform for API development that allows you to set up environments with preset variables, share API collections, streamline CRUD requests, and more. Most Platform API services have Postman collections which can be used to assist with making API calls.
The following video guide outlines creating and setting up your Postman environment. A Postman environment contains all the required headers you need to make API calls to the various collections provided below. Once set up, any time a value expires (such as an ACCESS_TOKEN) you can update the current value in the environment, and this new value is used across all your collections.
A folder containing all the available Postman collections can be found by, visiting the Experience Platform Postman samples GitHub repository. Alternatively, a Postman collection link can be found in each individual swagger file in the API reference documentation on Adobe I/O.
To download a Postman collection, select Raw from the GitHub page to load the raw JSON file in a new tab. Then, right-click and select Save as to save the file to a local destination of your choice.
In order to utilize a Postman collection, you need to have an environment set up. Once you have completed your environment setup, select the Manage Environments selector in the top-right corner.
As noted in the Identity Management Service (IMS) Postman collection, the denoted generation methods are suitable for non-production use. Local signing loads a JavaScript library from a third-party host, and remote signing sends the private key to a web service that is owned and operated by Adobe. While Adobe does not store this private key, production keys should never be shared with anyone.
This document introduced Postman environments, collections, and how to import collections. Now that you have Postman ready, visit the Platform getting started guide for information on required headers, examples, and a list of API guides available for each Platform service.
The Postman collection uses environment variables for authorization. That allows you to enter your account ID and access token in one location, rather than having to do it for each request. This makes it easier to set up, and easier to change if you want to use the collection as a different user. To acquire an access token and see your account ID, click here and select Create New Personal Access Token.
But hopefully this use case (especially with the recent change to enable write access to collection variables from scripts) highlights my argument for collection variables being a more specific scope than environment variables (and thus, being used when there are variables of the same name for both scopes)
1st: local, which can be used across an execution (as specific as a single request)
2nd: collection, which can be used across a collection
3rd: environment, which can be used across collections
4th: global, which can be used across collections and across environments
Hi there
I to think it not very usefull, that environment variables take precedens over collection variables. As @morleym_cubic expresses, collection is a narrower scope than environment. By the current behavior, it is not possible to override an evironment variable with a collection variable. So we can not have different collections that uses local values to replace default values in the environment.
According to Postman docs: -and-environments/variables/#variable-scopes , collections are a narrower scope than environments and a collection variable should take precedence over an enviroment variable. The principle is mentioned in the docs for global and local:
Earlier I tried adding another part of the response into another environment variable, and realised the entire collection was unable to update the environment.
EDIT: This is when the collection is run from the collection runner. IF the requests are sent one by one it is fine.
Oh yes i have done the mistake of not having saved a request properly before, so I made sure this was not the case here before posting.
Alright for visuals, here is the last request from my collection
image851369 20.7 KB
This EventListenerId is the result of a previous request, and must be up-to-date to function properly, which is what I mentioned previously.
the last two pm.environment.set are there for this test.
If I run this collection, no error from lack of eventListenerId, but none of the environment variables change .
I realised that if I send the requests one by one (without the runner), the environment is updated properly. This is highly impractical though.
After I had created the account I opened the installed Postman again and I fell into the trap. All my collections and environments had disappeared. This was the most evil welcome gift I have received so far. With the help of Google and this thread I could recover the data. But these are experiences I can really do without.
df19127ead