skip to content

In a Postman script, what arguments does pm.sendRequest take, and how does the script receive the reply?

level: juniorimportance: should knowfreq 52%

answer

  1. The sandbox has no socket of its own
  2. URL string, or a request definition object
  3. Nothing comes back at the call site
  4. Node-style callback: error first, response second
  5. A 500 still arrives with err null

basics

~10 s

pm.sendRequest takes either a URL string or a request definition object, plus a callback. The call is asynchronous: it returns nothing useful, and the callback receives an error first and a response object second.

solid answer

~40 s

`pm.sendRequest` is the Postman sandbox's way for a script to put an HTTP exchange on the wire itself. Its first argument is either a plain URL string (a shorthand GET) or a request definition object with `url`, `method`, `header` and `body`; its second is a Node-style callback `(err, response)`. The call site gets nothing back — the work happens outside the sandbox, so anything that depends on the reply has to live inside the callback. `err` is filled only when the exchange itself failed (DNS, connect, TLS); a 4xx or 5xx is a perfectly successful exchange, and you read `response.code` to see it. The `response` handed to the callback is an SDK `Response`, so `.code`, `.headers`, `.text()` and `.json()` are available on it.

code

javascript · 11 lines
javascript
pm.sendRequest({
    url: 'https://example.com/api/config',
    method: 'GET',
    header: { accept: 'application/json' }
}, function (err, res) {
    if (err) {
        console.log('exchange failed:', err);
        return;
    }
    console.log(res.code, res.json());
});

go deeper

for a junior

Recall the two arguments — a URL string or a request definition object, plus a callback — and that the callback is where the reply shows up. Nothing useful comes back at the call site.

for a middle

Explain why the API is callback-shaped: the sandbox has no network stack, so the call is bridged to the host runtime and answered asynchronously. Be able to say what fills the error argument and what does not.

for a senior

Show you can debug the common failure: work written after the call instead of inside the callback, reading a value that does not exist yet. Know that an HTTP error status arrives as a normal response.

for a principal

Be ready to argue when a side call belongs in a script at all versus being a request the collection owns, and what that choice costs in visibility for whoever reads the run later.

## What `pm.sendRequest` actually is Postman scripts run inside a **sandbox** — an isolated JavaScript context with no network stack and no filesystem of its own. `pm.sendRequest` is the sandbox's door out. It does not open a socket itself; it raises a bridged command, internally `this.immediate('httprequest')`, that the **host runtime** picks up, performs and answers. That dispatch is tagged `source: 'script'`, the marker that tells the runtime this exchange was asked for by code rather than by a request stored in the collection. That architecture is why the API has the shape it has. The work happens on the other side of a bridge, so `pm.sendRequest` is **asynchronous and callback-based**, and it hands the call site nothing at all. ## The first argument: two shapes | Form | What you write | What you get | |---|---|---| | URL string | `pm.sendRequest('https://example.com/ping', cb)` | a GET, no headers of your own, no body | | Request definition | `pm.sendRequest({ url, method, header, body }, cb)` | full control over verb, headers and payload | The object form uses the same field names the SDK's `Request` understands — `url`, `method`, `header`, `body` — so a POST with a content type and a payload is expressible without leaving the script. ## The second argument: the callback contract The callback is **Node-style**, `(err, response)`, and the two positions mean different things: - `err` is populated when the **exchange itself** failed to happen — the name would not resolve, the connection was refused, the handshake failed. - `err` is `null` whenever a reply came back, **including a 404 or a 500**. An HTTP error status is a successful exchange as far as this callback is concerned. - `response` is an SDK `Response` object, not a raw string. `response.code` is the numeric status, `response.status` the reason phrase, `response.headers` the header list, `response.text()` the raw body and `response.json()` the parsed body. - Calling `response.json()` on a body that is not JSON throws, so guard it when the endpoint's content type is not guaranteed. ## The lifecycle, step by step 1. The script calls `pm.sendRequest` with a URL or a request definition. 2. The sandbox serialises that request and raises the bridged `httprequest` command, tagged `source: 'script'`. 3. The host runtime performs the exchange with its own HTTP machinery. 4. The host sends the serialised reply back across the bridge. 5. The sandbox rehydrates it into an SDK `Response` and invokes your callback with `(null, response)` — or with an error and no response if step 3 never completed. ## Where the code that uses the reply has to live This is the part that trips people up first. The statements written **after** the `pm.sendRequest(...)` line run immediately, long before any reply exists: - Anything that reads the response must be written **inside** the callback body. - Two side calls where the second needs the first one's answer means **nesting** the second call inside the first one's callback. - There is no return value to assign, so `const res = pm.sendRequest(...)` gives you nothing useful. - Because the reply arrives on a callback, an ordinary `try`/`catch` wrapped around the call site never sees a failure from the exchange; the error arrives as the callback's first argument instead. ## What this call is, and what it is not `pm.sendRequest` produces a real HTTP exchange, and that is all it produces. It is **not** a stored request being executed: - Nothing in the collection is consulted to build it — the script's own object is the whole request. - It has no identity in the run: it is not an item, so nothing about the run's sequence changes because of it. - **File data is stripped** out of a script-built body before the request is dispatched; the sandbox's own wording is that uploading files from scripts is not allowed. So the mental model to carry into an interview is a narrow one: `pm.sendRequest` is a plain, one-shot HTTP call made from script code, addressed by you, answered into a callback, and invisible to everything the collection knows about ordering and events. It is the right tool when a script needs a fact from some other endpoint before it can go on, and the wrong tool when what you actually want is the collection's own machinery to run.

  • The endpoint answered 503. Is the callback's first argument filled?
    No. `err` reports that the exchange could not happen at all — a name that would not resolve, a refused connection, a failed handshake. A 503 means the exchange completed, so the callback is invoked with `err` null and a `response` whose `code` is 503. Status handling is your job inside the callback.
  • Why can a second side call not simply be written on the next line after the first?
    Because `pm.sendRequest` returns immediately and the reply arrives later, the next line runs before any answer exists. If the second call needs a value out of the first reply, it has to be issued from inside the first call's callback; otherwise it will be built from an undefined value.

saying these in an interview costs you the question

  • Says pm.sendRequest returns the response synchronously
  • Assigns the call to a variable and reads the body from it
  • Believes a 404 or 500 fills the callback's error argument
  • Thinks the callback gives a raw string rather than a Response
  • Writes the follow-up work after the call instead of inside the callback