When Postman imports an OpenAPI definition, what does the converter's folderStrategy option decide?
answer
- The definition contains no folder tree
- An importer option, not a definition key
- Two groupings: URL structure or labels
- Paths or tags, chosen at import time
- Grouping only, never the URL sent
basics
~20 sfolderStrategy tells Postman's OpenAPI converter how to group generated requests into folders: one folder per URL path, or one folder per tag an operation declares. The definition carries no folder tree, so the importer invents one.
solid answer
~40 sAn imported collection's folder tree is not transcribed from the definition — the definition has no folders in it. The converter (`openapi-to-postman`) builds the tree, and `folderStrategy` is the option that chooses how: group by **paths**, so the tree mirrors the URL space, or group by **tags**, so it mirrors the labels the API's author put on each operation. The choice affects grouping only. Whichever setting you pick, each generated request keeps the same URL, method and body — moving an item between folders never rewrites what is sent. The practical consequence is that two engineers importing the same definition can end up with differently shaped collections, so the import options are worth agreeing on rather than leaving to whoever clicked import.
go deeper
Be ready to say that importing a definition builds the folders for you, and that folderStrategy is the option choosing between grouping by URL path and grouping by tag.
Explain that the definition holds no folder tree at all, so the converter maps operations onto a collection's nested shape. Stress that the option changes grouping only, never a request's URL, method or body.
Show the operational consequence: the same definition imports into differently shaped collections depending on options nobody recorded. Agree the import settings up front and treat the generated tree as a starting point you will reshape.
Own the question of whether an imported collection is a throwaway artefact or a maintained one. Once examples, scripts and edits accumulate inside those folders, who may reshape them, and what a fresh import is allowed to do, becomes a team decision.
## What the option decides An OpenAPI definition describes **endpoints**; a Postman collection is a **tree of folders and requests**. Nothing in the definition states what that tree should look like, so the converter that runs behind the import (`openapi-to-postman`) has to invent one. `folderStrategy` is the option that tells it how. It offers two groupings: by **paths**, or by **tags**. Everything else about the generated collection is decided by other options on the same converter — `requestNameSource` decides what each request is called, `schemaFaker` and the two `*ParametersResolution` options decide where sample values come from, `preferredRequestBodyType` decides which single media type becomes the body. `folderStrategy` decides only the **shape of the tree**, and nothing else. ## Paths versus tags | `folderStrategy` | What becomes a folder | The collection you end up reading | |---|---|---| | paths | the URL path of each endpoint | mirrors the URL space, nesting the way the paths nest | | tags | the tag an operation declares | mirrors how the author grouped operations by feature | - **Paths** is the grouping you want when you navigate the API the way a client does — by URL. A reader who knows the endpoint can find the request by walking the same segments they would type. - **Tags** is the grouping you want when the API's author has already done the work of labelling operations by feature area, and those labels are more meaningful to a human than the URL structure is. - Neither grouping is **more correct**. They are two projections of the same set of operations, and the converter cannot pick for you because the definition does not express a preference. - Neither grouping changes a request. The URL a request sends lives on the request itself; the folder it sits in is organisation, not addressing. ## Why the tree is a converter decision, not the definition's This is the point interviewers are actually probing, and three consequences follow from it: 1. **The folder tree is not part of the API contract.** Nobody consuming the API sees it. It exists only in the artefact the import produced, and it is safe to reshape by hand afterwards — you are editing a local organisation scheme, not the API. 2. **The same definition yields different collections.** Import with one setting and you get a URL-shaped tree; import with the other and you get a feature-shaped one. If the imported collection is shared, the shape someone else sees depends on options they never saw. 3. **Reviewing an imported collection means reviewing choices.** When a generated collection looks wrong, the first question is which converter options produced it, not whether the definition is wrong. The definition may be perfectly fine and the output still not what you wanted. ## What the import does and does not own The import owns the mapping from a definition to a collection. It does not own either side of that mapping, and it is worth being precise about where the boundaries fall: - **How a folder is represented in the saved file** — what makes an entry a folder rather than a request, how ordering is expressed, how folder-level auth and events are resolved for an item nested inside — belongs to the collection's own folder structure. That is true of any collection, imported or hand-built. - **What the definition contains** — its top-level keys, operation objects, schemas and references — belongs to the OpenAPI document itself, not to the converter. - **The choices in between** — grouping, naming, sample values, which body survives — are the converter's, and `folderStrategy` is the first of them. ## Reading an imported collection A short checklist when you inherit one and something looks odd: - Ask which `folderStrategy` produced it before assuming the definition is disorganised; a flat-looking tree can simply mean the operations carry no useful labels. - Do not read folder names as though they were API structure. They are a view, chosen at import time. - Expect to reshape the tree by hand once real work accumulates in it — the generated grouping is a starting point, not a maintained mirror of the definition. - If several people work from the same imported collection, write down the import options alongside it, or the next import will disagree with the current tree for reasons nobody can reconstruct. The short version an interviewer wants back: the definition has no folders, the converter has to invent them, `folderStrategy` is that decision, and it changes grouping only — never what a request sends.
- If you re-run the import with folderStrategy set to tags instead of paths, does anything about the requests themselves change?No. The option changes grouping only. Each generated request keeps the URL, method, headers and body the converter derived from the operation; only the folder it lands in differs. Folder membership is organisation, not addressing, so nothing about what gets sent moves with it.
- Why can't the OpenAPI definition simply declare the folder tree the import should build?Because a folder tree is a collection idea, not a definition idea. The definition describes endpoints and says nothing about how a client tool should organise them. The converter has to map one onto the other, that mapping is under-determined, and folderStrategy exists precisely to let a human resolve it.
- Someone renames and rearranges the folders in an imported collection. What breaks?Nothing about the requests. Folder names are a local view, not part of the contract, so rearranging them changes only navigation. What it does break is the resemblance to the next import: a fresh conversion rebuilds the generated shape, and the hand-made organisation is not something the converter knows about.
saying these in an interview costs you the question
- Claims the OpenAPI definition declares the folder tree
- Thinks folder names form part of the API contract
- Says moving a request between folders changes its URL
- Believes the converter derives folders from the server URL
- Assumes every import of one definition yields the same tree