In a Postman collection imported from OpenAPI, why do request values look faked while saved examples do not?

## The asymmetry When a definition is converted into a collection, every generated request needs values in it — something in the body, something for each parameter — and every generated saved example needs a payload too. The converter fills both, but **not from the same place**, and the defaults are what make an imported collection confusing on first read. | Side of the request | Converter option | Default | Where its values come from | |---|---|---|---| | the request being sent | `requestParametersResolution` | `Schema` | **faked** from the declared types | | the saved example | `exampleParametersResolution` | `Example` | the **examples the definition supplies** | So the body you are about to send was invented by a generator, and the body shown as the expected reply was written by a human and carried across. Two payloads, side by side in the same item, with completely different provenance. ## What "faked from the schema" means The generator behind that default is controlled by the `schemaFaker` option. Working from the declared shape of a payload, it produces a value of the right kind for each field: something string-shaped where a string is declared, something numeric where a number is declared, a nested object where the shape nests. The output is structurally correct and semantically meaningless. That distinction matters more than it sounds: - **Structurally correct** means the request will usually serialise and often parse on the far side. It looks like a real call. - **Semantically meaningless** means the identifier in it refers to nothing, the amount is arbitrary, and the enum-ish string may be a value the domain never uses. - **No cross-field consistency** should be assumed: two fields that must agree in the real domain were generated independently. - **Nothing was reviewed.** No human approved these values; a type declaration was expanded mechanically. ## Why the example side is different The example side defaults the other way for a reason that is easy to state: **when a human has already written a realistic payload, use it.** Definitions commonly carry example payloads for responses precisely so that documentation renders something believable, and the converter treats that as better material than anything it could invent. Hence `exampleParametersResolution` defaulting to `Example` while the request side defaults to `Schema`. The two options are independent, so the behaviour is adjustable in both directions: 1. Point the request side at examples, and generated requests will prefer written example values where the definition supplies them. 2. Leave the defaults alone and treat every request value as a placeholder to overwrite before the call means anything. 3. Control whether values are generated at all through `schemaFaker`, which is the knob for the faking behaviour itself rather than for which source is preferred. ## Where this bites in practice - **Someone runs the imported collection as a smoke test.** The calls are well-formed and fail on business validation, and time is lost debugging a service that is behaving correctly against invented input. - **Someone reads a faked value as documentation.** A generated identifier gets copied into a ticket or a test fixture as though it were a real example from the API. - **Someone dismisses the collection wholesale.** Having noticed the fake request values, they assume the examples are fabricated too — but those came from the definition and are usually the most trustworthy content in the file. - **Someone commits the generated values.** The invented payloads become the team's de-facto sample data, drifting further from reality with every import. ## What to do about it - Treat a freshly imported request body as **a shape to fill in**, never as data. Its job is to show you which fields exist. - Read the saved examples as the definition's own material, because that is what they are — and if they are poor, fix them in the definition where every consumer benefits. - If your definitions carry good request examples, change the request-side resolution so the import uses them instead of faking. - Say the asymmetry out loud when handing the collection to someone else. "Requests are faked, examples are real" saves the next person the confusion you just went through. ## The short answer Request values are generated from the declared schema because `requestParametersResolution` defaults to `Schema`; example values are copied from the definition because `exampleParametersResolution` defaults to `Example`. Same import, same item, two different sources — and knowing which is which tells you exactly how much to trust each payload.