In a Postman collection, how does an `auth` type of `noauth` differ from a `null` type during inheritance?

## Two ways to say "no credentials", only one of which means it When you want a request under an authenticated collection to go out with nothing attached, there are two things the file can say and they behave oppositely. One is an **opt-out**: `{ "type": "noauth" }`. The other is an **absence**: no `auth` member, an `"auth": null`, or a block whose `type` is `null`. The first stops inheritance; the second is invisible to it. Confusing them is the single most common way a request ends up signed when someone meant it not to be, or unsigned when they thought a parent covered it. ## Why noauth stops the walk The SDK's parent lookup applies one predicate at each level: the entity has a truthy `auth`, and `RequestAuth.isValidType(auth.type)` returns true. That check asks only that the type be a **string** that is not literally the word `type` — a guard against colliding with the type selector inside the block. `"noauth"` is a perfectly ordinary string, so it passes, and there is no special case anywhere in the resolver that treats it differently from a named scheme. The walk therefore terminates at that level and returns the `noauth` block as the winner. What happens next is on the **runtime**. It ships a `noauth` handler, so this is a resolved type with a real implementation rather than a hole. That handler's `sign` step returns without touching the request, and its checks pass unconditionally. The request is sent exactly as written. The important consequence for a reader of the file: the collection's or an outer folder's credentials are never even consulted, because resolution already finished. ## Why a null type does not A `null` type fails the string test, so the level does not qualify and the lookup moves on. The SDK reinforces this at construction time as well. Both the request and the folder constructors build an auth object only for a truthy definition, guarded by a comment that says an empty one "should not be created for falsy values **to allow inheritance from parent**". If a falsy `auth` produced an empty object, that object would pass the truthiness half of the predicate and silently sever inheritance — the exact bug the guard exists to prevent. | What the level declares | Qualifies for the lookup | Walk behaviour | Outcome for the request | | --- | --- | --- | --- | | `{ "type": "noauth" }` | yes | stops at this level | sent unsigned, deliberately | | `{ "type": null }` | no | continues outward | whatever an ancestor declares | | `"auth": null` | no | continues outward | whatever an ancestor declares | | no `auth` member | no | continues outward | whatever an ancestor declares | | a named scheme | yes | stops at this level | signed with that block | The format permits every row of that table at all three declaration sites: the collection, a folder and a request each write `auth` as `oneOf` a null value or an auth object, so a null there is valid input, not a malformed document. ## The same distinction from code The SDK's setter mirrors it. `Request.authorizeUsing(type, options)` — the same function that `ItemGroup.authorizeRequestsUsing` binds onto a folder or a collection — treats `null` as a **delete**: it removes the `auth` property outright and returns, before the type-validity check ever runs. Calling it with the string `noauth` takes the other branch and installs a block. So the two operations are: - `authorizeUsing(null)` — remove the declaration; the level becomes transparent again and inheritance from the parents resumes. - `authorizeUsing('noauth')` — install a declaration that says "stop here, sign nothing". Neither raises an error, and nothing in the file distinguishes them after the fact except whether an `auth` member is present. ## Which one to write When a subtree genuinely should not carry credentials — a health check, an unauthenticated discovery endpoint, a public search — declare `noauth` on the folder. That is a statement someone can read and review, and it survives the request being edited later. Relying on absence instead is fragile in the other direction: absence means "whatever my ancestors say", and the day a root-level block is added, every silent request under it starts signing without anyone touching those requests. The converse also matters when reading. Seeing no `auth` on a request tells you nothing about whether it authenticates. Seeing `noauth` tells you it does not, and tells you somebody decided that on purpose. That difference in **legibility** — not any difference on the wire, since both end unsigned in the end — is the real reason to prefer the explicit form.