Postman

body.mode names one of raw, urlencoded, formdata, file or graphql, and the payload sits under a key spelled the same as the mode. Only that one key is read.

A Postman collection entry is a folder when it carries its own item list instead of a request. One array holds both kinds, so folders nest inside folders with no separate structure.

A collection stores a request's url either as one flat string or as an object of raw, protocol, host, path, port, query, hash and variable. Only the object form lets a tool address and edit a single part.

body.options.raw.language labels what a raw payload is written in. From that label the runtime derives a Content-Type header marked system true, but only when the request declares no Content-Type of its own.

A saved example's originalRequest is a whole embedded request definition, not a pointer back at the item. Editing the item's own request never touches that copy, so the example keeps documenting a call the request no longer makes.

Collection variables live in the collection document's own variable array, a field of the file itself, so they travel with every export and every commit. Scripts read them through the sandbox object pm.collectionVariables.

Postman's dollar-prefixed placeholders are generators supplied by the collection SDK: {{$guid}}, {{$timestamp}}, {{$isoTimestamp}} and {{$randomInt}} manufacture a value while the request is assembled. Nothing is read from a saved store and nothing is kept afterwards.

A Postman environment file is a separate JSON document holding an id, a name and a values array of key, value, type and disabled entries. A run is pointed at one file and loads it as a variable scope.

pm.variables walks a fixed chain and returns the first non-disabled match: its own local values, then iteration data, then the environment, then collection variables, then globals. An environment value therefore beats a collection variable.

Nothing supplied a usable value for that name. The substitutor replaces a double-brace match only when the lookup yields a string, number or boolean; otherwise it returns the matched text unchanged, so the token itself is sent.

A script attached to a Postman folder runs for every request nested beneath it, at any depth, including requests inside sub-folders. It never reaches requests outside that folder.

Nowhere on its own. The sandbox's console dispatches an execution.console event carrying the cursor, the level and the serialised arguments out to whatever host runs the script, and the host decides whether to display it.

Ancestors first: the collection's script, then each folder's from outermost inward, then the request's own. The Postman SDK's EventList.listeners orders inherited listeners ahead of the item's own, and all of them run.

Five and only five: url, method, headers, body and auth. Those are the mutations the runtime reads back out of a pre-request script; anything else the script assigns is not carried into the send.

Exactly two: prerequest, which runs just before the request is handed to the transport, and test, which runs after the reply arrives. No third, post-send listener name exists in the format.

Postman's status matcher is polymorphic: hand it a number and it compares the reply's status code, hand it a string and it compares the reply's reason phrase instead. statusCode and statusReason are the single-purpose spellings.

Postman's body matcher reads the reply as raw text and takes a string or a regular expression; jsonBody parses the reply first and then takes a path, an expected value, or an object. Both hang off pm.response.to.have.

Postman's jsonSchema assertion validates a value against a JSON Schema object using Ajv. Chained off pm.response it parses the reply body first; chained off pm.expect it validates whatever value you handed in.

Exactly one. A pm.test block is the reporting unit: it emits a single record carrying a name, a passed flag, a skipped flag, an error slot and an index, however many pm.expect calls sit inside it.

Containment. A throw inside pm.test is caught by that block: the block is recorded as failed and the script keeps going. A throw outside any block escapes, ends the script execution and surfaces as an execution error, not an assertion.

Read the value out of the reply in a test script, then write it into a tracked store with pm.environment.set, pm.collectionVariables.set or pm.globals.set. The next request refers to that same name.

Postman's runtime carries only three scopes back from a script - globals, environment and collectionVariables, the list its item command declares as trackContext. pm.variables.set writes a fourth, execution-local layer that is thrown away when the script ends.

pm.execution.setNextRequest records a target for the run's cursor rather than jumping. The current item finishes normally, then the runtime seeks to the named request. The last call made during that item wins.

The runtime matches the value against the run's items, ids before names. A value matching neither — a typo — or an explicit null sets the position to the iteration end, so the run stops silently.

It gets no events and no place in the run. Because a script builds it rather than the collection holding it, no item exists, so no pre-request or test script fires for it and the sequence of requests is unchanged.

A terminal run gets only the collection file plus what the command line hands it. The app's selected environment, its accumulated cookies and its transport settings are app-side state; anything the requests depend on must be passed explicitly.

Newman's -d flag takes a data file and runs the whole collection once per row. Each row becomes that iteration's pm.iterationData scope, so a script reads its columns with pm.iterationData.get('column').

In Newman, --folder narrows a run to one part of the collection: it takes the name or id of a folder or of a single request, and only that subtree executes.

Newman neither wraps nor fails: iterations past the data file's last row repeat that last row. A count smaller than the row count simply runs the leading rows and never reaches the rest.

The first match wins and only it runs. Newman's --folder lookup compares ids and names and takes own children before deeper ones, so a top-level folder beats a same-named folder nested further down.

The collection format allows an auth block in three places: the collection document itself, a folder, and a single request. Resolution is nearest-wins, so a request's own block beats a folder's, and a folder's beats the collection's.

The auth object's required type field names the scheme, and that scheme's settings sit in a sibling array with the same name, holding auth attributes. Only key is required on each attribute.

Item.getAuth() extracts the request's own auth first, then calls findInParents to walk the parent chain outward. It returns the first ancestor declaring a block whose type is a usable name, and undefined if none does.

A pre-request script stores the fetched token in a variable scope; the collection's oauth2 accessToken attribute holds a brace token naming it. The runtime resolves auth variables before the handler signs, so signing sees the real value.

The request goes out unsigned. The SDK stores almost any scheme name, the runtime's handler lookup misses, a console warning naming the type is triggered, and the run continues as if no credential had been configured.

A run keeps one cookie jar: the store every request in that run reads from and every response writes into. Scripts open it with pm.cookies.jar(), while pm.cookies lists what the jar holds for the current request's URL.

Postman's Certificate.canApplyTo rejects any non-https URL before it ever tests the entry's match patterns, so a plain http call is short-circuited out of certificate selection no matter how well the patterns fit.

The request's value wins. Postman's SDK resolves an item's protocolProfileBehavior by walking every ancestor including the collection root and merging their blocks member by member, so the declaration nearest the request decides each member.

ProxyConfig.test checks the bypass list before the match pattern, so any bypass hit ends the evaluation and the request goes direct no matter what match says. Bypass is a veto, not a tie-breaker.

Check three things in order: the URL's scheme, since a non-https URL is rejected first; the list order, since the first matching entry wins; and the key and certificate paths, since a failed file read only warns.

A Postman mock server replies with the examples already saved beside the requests in the collection it was created from. Those examples live in a Postman account, and anyone allowed to edit that collection can edit them.

A collection in a shared Postman workspace lives in the vendor's hosted account, not in your repository. Anyone the workspace admits can edit it, and the edit takes effect immediately, with no commit and no review.

A Postman mock server fuses the documented reply and the served reply into one saved example, so a single edit by anyone with collection edit rights moves documentation and stand-in together, with no diff or review on the consumer's side.

Whoever holds the vendor account finds out first, not whoever caused the failure. The notice carries a time and a failed request but no commit, no author and no build, so attribution has to be reconstructed by hand.

A Postman fork keeps a recorded link back to the collection it came from, so later work can be offered back and merged through a review held in the vendor's account. A duplicate is an orphan.