Overview
Recently I started importing collections using OpenAPI JSON-files. Of course this gives all advantages of having parameter types in requests, JSON-body’s verification and so on. Below are some examples:
Unfortunately those advantages of importing from OpenAPI JSON-files are not achieved with official Postman’s Collection Export feature. This important information is just lost while exporting Postman’s collection.
Bottleneck Examples
I’m showing examples of those two requests first with OpenAPI JSON-file and then with the Postman’s export one:
Parameter type Loss:
OpenAPI
-
"/Campaign/{number}": { "get": { "tags": [ "Campaign" ], "summary": "campaign-get-get", "operationId": "campaign-get-get", "parameters": [ { "name": "number", // here is our parameter's name "in": "path", "required": true, // whether it is required "schema": { "type": "integer", // and it's type "format": "int32" } } ], "responses": "{...}" } }
Postman Collection Export
-
"name": "campaign-get-get", "request": { "method": "GET", "header": [...], "url": { "raw": "{{baseUrl}}/Campaign/:number", "host": [...], "path": [ "Campaign", ":number" ], "variable": [ { "key": "number", // here is our parameter's name "value": "5111", // only value, which was generated at initial import from OpenAPI JSON-file "description": "(Required) " // generated string from Postman in parameter's description at initial import from OpenAPI JSON-file } ] } }, "response": [...]
Body’s Schema Loss
OpenAPI
-
"/ArticleOverall": { "post": { "tags": [ "ArticleOverall" ], "summary": "articleoverall-get-post", "operationId": "articleoverall-get-post", "requestBody": { "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ArticleOverallPagedRequest" }, // ⇧Reference of allowed body object. It contains rules of request body (See the second screenshot in the beginning.) "example": {...} // Example of request's body. }, ... } }, "responses": {...} } }
Postman Collection Export
-
"name": "articleoverall-get-post", "request": { "method": "POST", "header": [...], "body": { "mode": "raw", "raw": "{\n \"filterText\": \"string\",\n \"itemsPerPage\": 0,\n \"pageToDeliver\": 0,\n \"sortDirection\": 0\n }", "options": { // ⇧That's all info what Postman exports. No schema. Just raw example of the body, despite of seeing body's schema in collection I've exported from. "raw": { "headerFamily": "json", "language": "json" } } }, "url": {...} }, "response": [...]
This makes “Collection Export“ incomplete and ends up with you getting simpler and less detailed collection exported. After you import that exported JSON-file, you won’t have any schemas or parameter types involved.
- No schema is present for request body
- No
configuration for parameters (Collection’s “Types feature“ will simply be turned off.)
Unobvious Consequences (despite of initial problem)
I’ve found literally the same behavior with some other features.
- Moving the collection to other workspace.
- Duplicating the collection inside the same workspace.
That allows me to guess that whenever you are choosing “Duplicate“ or “Move” your collection, Postman internally creates this proprietary incomplete export JSON-file and imports it again, whether it is the same or different workspace.
Whats now?
I’ve not found any way to “make” Postman do the complete exporting or duplicating. So, if you are using complex collections with: schemas, “Types feature” enabled or collection is imported from OpenAPI JSON-file, the only thing is left to recommend: stick with using OpenAPI JSON-files further. Using of “Export -“, “Move -“ or “Duplicate feature“ will reduce complexity of your collection.
Would love to get some feedback from someone who faced same issues or/and found any workarounds!



