skip to content

In a Postman collection generated from an OpenAPI definition, where do the request names come from?

level: juniorimportance: should knowfreq 42%

answer

  1. A converter option, not a definition field
  2. Prefers human prose over machine tokens
  3. Falls back when the summary is missing
  4. Camel-cased names mean absent summaries
  5. requestNameSource, on the OpenAPI importer

basics

~10 s

Request names in an imported collection come from the converter's requestNameSource option. Its default takes the operation's human-readable summary text and falls back to the operation's identifier when no summary exists.

solid answer

~40 s

Every item in a collection carries a display `name`, and an import has to produce one for each generated request. The converter's `requestNameSource` option decides how. Its default prefers the operation's human-readable summary text, and **falls back to the operation's identifier** when the definition supplies no summary — which is why an imported collection often reads as a mix of sentences and camel-cased identifiers. The option can instead be set to name each request after its URL. The takeaway for a candidate: unreadable request names in a generated collection are usually a gap in the definition's prose rather than a bug in the importer, and the fix is to add summaries upstream, not to rename items downstream where the next import will not see them.

go deeper

for a junior

Be ready to say the importer names each request from the operation's summary text, and uses the operation's identifier when no summary is there. Know that requestNameSource is the option controlling it.

for a middle

Explain the fallback as a converter decision, not a definition rule, and describe why the identifier is a sensible last resort: stable, unique, and attached to the operation rather than to a path that may move.

for a senior

Demonstrate that you fix names upstream. Renaming items patches one artefact; adding summaries to the definition improves every future import and every other reader of the document.

for a principal

Frame readable operation summaries as a quality bar the definition has to meet, since generated clients, generated docs and imported collections all read from the same prose. Decide where that bar gets enforced.

## The problem an import has to solve A collection stores a display `name` on each item — that is the string you see in the sidebar. An OpenAPI definition, by contrast, describes an operation with several pieces of text and no single field marked "call this in a UI". Something has to choose. The converter behind Postman's import (`openapi-to-postman`) exposes that choice as the `requestNameSource` option. This is the same class of decision as `folderStrategy`: the definition under-determines the collection, and the converter resolves it with an option you can set. The difference is that a bad naming choice is far more visible, because it is what everyone reads first. ## The fallback chain | What the converter finds on the operation | The name the request gets | |---|---| | human-readable summary text | that text, used as written | | no summary text | **the operation's identifier** | | the option set to name from the URL instead | the endpoint's URL | The fallback is the part worth remembering. An identifier is written for machines: it is unique and stable, which is exactly what a generated collection needs, and it is frequently unreadable, which is exactly what a human browsing a sidebar does not need. So a collection generated from a definition whose authors skipped the prose reads as a list of camel-cased tokens, and that is the converter behaving correctly rather than failing. ## Why the names matter more than they look - **They are the whole navigation surface.** Nobody reads a saved collection's raw file to find a request; they scan names in a tree. Bad names make a technically complete collection unusable. - **They are the first evidence of definition quality.** A generated collection is an honest mirror of how much human-readable text the definition carries. If half the requests are identifiers, half the operations have no summary. - **They are stable in a useful way.** Because the fallback is the operation's identifier rather than something positional, the same operation converts to the same name every time, even as paths are reorganised around it. - **They are not a contract.** Like the folder tree, names exist in the generated artefact only. Consumers of the API never see them. ## Where to fix a bad name There are two places to intervene, and they behave very differently: 1. **Upstream, in the definition.** Add the missing summary text to the operation. Every future import — yours and everyone else's — picks it up, and the definition gets better for its other readers too. This is the fix that compounds. 2. **Downstream, in the collection.** Rename the item by hand. It works immediately and helps exactly one copy of one artefact. A later conversion of the same definition regenerates names from the same source and knows nothing about the edit. The judgment an interviewer is listening for is that renaming in the collection treats the symptom in the artefact, while adding the summary treats the cause in the source everyone converts from. ## Staying on the right side of the boundary Two things are easy to conflate here: - **The identifier itself belongs to the definition.** What an operation's identifier is for, what constraints it carries, and how the rest of the definition may reference it are questions about the OpenAPI document, not about the import. The import's only claim is narrow: when no summary exists, that identifier is what the generated request is named. - **The `name` on a saved item belongs to the collection format.** It is an ordinary display string on any item, generated or hand-made, and the importer simply fills it in like any other author would. ## The short answer Request names in an imported collection are produced by the converter, controlled by `requestNameSource`, sourced from the operation's human-readable summary, and fall back to the operation's identifier when that summary is absent. If the collection reads badly, look at the definition's prose before blaming the tool.

  • An imported collection is full of camel-cased request names. What does that tell you about the definition?
    That those operations carry no human-readable summary text, so the converter fell back to each operation's identifier. It is a gap in the definition's prose, not a converter fault. The durable fix is to add summaries upstream so every future import reads well, rather than renaming items in one copy.
  • Why does the fallback use the operation's identifier rather than something like the URL and method?
    Because the identifier is a single stable token attached to the operation itself, so the same operation converts to the same name across imports even if paths are reorganised. Naming from the URL is available as an explicit setting, but it makes the name depend on structure that moves.

saying these in an interview costs you the question

  • Thinks the collection format dictates the name source
  • Says request names are copied from the URL by default
  • Believes renaming an item upstreams into the definition
  • Assumes unreadable names mean the importer failed
  • Claims names are part of the published API contract