API & DB clients
Driving a live service by hand, then replaying those calls unattended: request builders, saved collections and terminal runs. Interviewers ask because that is how a bug becomes a standing check.
on this pageshowhide
guide
overview
~1 minAn API client is the tool you use to drive a running service by hand: compose a request, send it, read what came back, adjust, send again. Interviewers care less about which buttons you know than about the step that follows. Once a call reproduces a bug or proves a feature, can you save it, parameterise it, attach a check that judges the reply, and replay the whole set unattended in a build? That move, from an exploratory call to a standing check, is what this subject is really about. The subject splits into three tools of very different weight. [Postman](/topics/dev-postman) is the bulk of it: a saved collection of requests, the variable stores that feed them, the scripts that run before a send and after a reply, the auth helpers, the transport settings, and the hosted features (shared workspaces, mock servers, scheduled runs) that live in the vendor's account rather than in your repository. [Newman](/topics/dev-newman) is the command-line runner for those collections, and it is how a collection becomes a build step with a written report and an exit code. [SoapUI](/topics/dev-soapui) covers the other lineage: requests generated from a machine-readable service description instead of typed, kept as a suite, with a stand-in service beside them, a lineage many enterprise integrations still depend on. Start with the collection itself and its variable stores, because nearly every later question assumes you know where a value comes from and where a script's write goes. Then the scripts and assertions, then running a collection from a terminal. Junior questions ask what a feature does; senior and principal ones ask what a shared, hosted or generated setup silently fails to guarantee, and who notices when it breaks.
primer
A few ideas carry most of this hub. With them in place, the questions below read as consequences rather than trivia. - **A saved request is a document, not a click history.** A collection is a structured file: requests, folders, auth blocks, scripts and example replies, nested in a tree. Much of what surprises people (ordering, which folder a script reaches, why an example drifts from its request) follows from reading that document's shape instead of the app's screen. - **Values are looked up, not stored in the request.** A request holds placeholders; a run resolves them against several stores with a fixed precedence. Knowing which store wins, which stores travel with an export and which survive past the script that wrote them explains most "works on my machine" reports. - **Scripts run at two points and inherit down the tree.** One hook fires before the send, one after the reply, and scripts attached higher up the tree run for everything beneath them. The useful questions are about reach and order, and about what a script can actually change on the outgoing call. - **An assertion is only as good as its reporting unit.** A check that never ran, a failure that escaped the block meant to record it, or a spelling that still passes through a compatibility layer can all look green. Judge a test by what a failure would look like in the report. - **The app hides state that a headless run does not have.** The selected environment, accumulated cookies and transport settings live in the app. A terminal run knows only the file and its command line, so everything implicit has to become explicit. - **Hosted features move configuration out of version control.** Shared workspaces, mocks and scheduled runs are convenient and live in a vendor account, where edits take effect without a diff or review. Senior questions probe that governance gap more than the features themselves. - **Generated beats typed until the description is wrong.** Tools that build requests from a service description remove guesswork about shape, and inherit every error or staleness in that description.
- Collection
- A saved, shareable tree of requests and folders, with their scripts, auth settings, variables and example replies, stored as one structured document.
- Environment
- A named set of variables, kept in a separate file from the collection, that a run loads to target one deployment such as local, staging or production.
- Variable scope
- One of the layered stores a placeholder is resolved against; scopes differ in precedence, in whether they travel with an export and in how long a written value lives.
- Pre-request script
- Code attached to a request, folder or collection that runs before the request is sent, typically to compute values, fetch a token or adjust the outgoing call.
- Test script
- Code that runs after the reply arrives and records named pass or fail results by checking status, headers, body or timing.
- Sandbox
- The restricted scripting runtime that executes pre-request and test code, exposing a fixed object model rather than the full host environment.
- Auth inheritance
- Resolving which credential signs a request by taking the nearest declaration on the path from the request up to the collection.
- Request chaining
- Carrying a value from one reply into a later request, usually by writing it to a store that outlives the current script.
- Data-driven run
- Executing a collection once per row of an external data file, with each row's columns available to scripts and placeholders.
- Reporter
- A pluggable output of a command-line run that turns results into a format such as terminal text, JSON or JUnit XML for a build to consume.
- Mock server
- A hosted stand-in that answers requests from replies saved in a collection, letting consumers work before or without the real service.
- Scheduled run
- A collection executed on a timer by the vendor's infrastructure, used as a lightweight uptime or contract check against a live service.
- Service description
- A machine-readable contract such as a WSDL or an OpenAPI document, from which a tool can generate requests, folders or stand-ins.
The three sections are one pipeline seen at different stages, and most of the hub sits in the first one. ### From a hand-typed call to a collection Everything starts in the [collection document](/topics/dev-postman-collection): a tree of requests and folders. [Variable stores](/topics/dev-postman-variables) feed it values, [auth helpers](/topics/dev-postman-auth) sign it, and [transport settings](/topics/dev-postman-transport) decide how bytes reach the network (cookies, certificates, proxies). These are the static parts: they describe a call without deciding anything at run time. ### Behaviour at run time [Sandbox scripts](/topics/dev-postman-scripts) add behaviour around each send. [Verifying a reply](/topics/dev-postman-assert) is scripting aimed at a verdict, and [cross-request flow](/topics/dev-postman-flow) is scripting aimed at the next request: passing ids forward, fetching tokens, changing the run's order. Both depend on the variable stores, because a script's writes only matter if a later step can read them. ### Unattended execution and the hosted side [Batch execution](/topics/dev-postman-run) replays a collection over iterations, data rows and selected folders. [Newman](/topics/dev-newman) is the headless form of that run, and the point where the pipeline meets CI through reporters and an exit code. [The vendor's side](/topics/dev-postman-platform) (workspaces, mocks, scheduled runs) is an alternative home for the same collection: convenient and shared, but outside the repository and its review. [SoapUI](/topics/dev-soapui) is a parallel track rather than a later stage. It reaches the same end state, a re-runnable suite with a stand-in, from the opposite direction: the service description generates the requests, where a collection usually starts from typed calls, though it can also be imported from a description.
- Collection Document →
The file every other section reads from; knowing how requests, folders and examples are stored explains ordering, scope and drift questions later.
- Variable Stores →
Nearly every script, auth and run question turns on which store a value comes from, which wins, and which survives an export.
- Sandbox Scripts →
Learn the two hooks, their order down the tree and what they can change before studying assertions or flow control.
- Verifying a Reply →
Turns a script into a verdict; the reporting rules decide whether a failure ever shows up in a run.
- Batch Execution →
Iterations, data files and folder selection are the bridge from a hand-clicked collection to a repeatable run.
- Newman →
The command-line runner is where a collection meets the build: reporters, exit codes and what a terminal run cannot see.
Saying a value is "set" without naming the store; a write to the wrong scope is either gone before the next request or missing from the teammate's import.
Trusting a green run without asking whether each check could have failed; an unreachable assertion or a throw outside its block does not read as a failed test.
Moving a collection from the app to a terminal run and forgetting the app-side state it quietly relied on: the selected environment, cookies and certificates.
Wiring a command-line run into CI without checking what makes it exit non-zero, then finding the build passes while the report shows failures.
Treating a mock built from saved examples as proof the real service behaves that way; it proves only your own side of the exchange.
Letting a scheduled hosted run become production monitoring with no owner, no review of edits and no alert when it is paused.
Assuming a request generated from a service description is correct because a tool produced it; it is only as current as the description.
Controlling run order by script jumps whose target is a name typed as a string; a rename or typo can end the run early without a clear error.
The recurring choices in this hub are less about features than about where things live and who can change them. - **Hosted workspace versus repository.** A shared workspace makes a collection instantly available and editable; a file in the repository gets diffs, review and history. The deciding question is whether the collection is a scratchpad or something a build, a consumer or a monitor depends on. - **App run versus command-line run.** The app is fast for exploring and debugging because it carries state between sends. A headless run is reproducible because it carries nothing it was not given. Anything that must be trusted in CI belongs in the second form. - **Scripted flow versus independent requests.** Chaining values and jumping between requests models a real user journey, but couples requests so one failure cascades and order becomes load-bearing. Independent requests with their own setup are slower to write and easier to diagnose. - **Generated versus hand-written requests.** Generating from a service description removes typing errors and keeps coverage aligned with the contract; hand-written requests capture intent and edge cases a description does not state. Generated suites need regenerating when the description moves. - **Mock versus real dependency.** A stand-in gives deterministic, offline tests of your own side; only the real service can reveal that its behaviour differs from its documentation.
Several shapes repeat across the questions under different names; recognising them makes an unfamiliar question easier to place. - **Nearest declaration wins.** Variable lookup, auth inheritance and script cascades all resolve something by walking a hierarchy, and the answer usually depends on which level is consulted first and whether the others still run. - **What travels with the file.** Many questions reduce to whether a value, setting or credential is part of the exported document, a separate file, app-side state or vendor-account state. The answer predicts what a teammate or a CI job will see. - **Silent fallback.** An unresolved placeholder sent as literal text, an unknown auth scheme leaving a call unsigned, a lookup miss ending a run: several failures here produce no error, only a wrong result. Expect interviewers to ask how you would notice. - **Copy, not reference.** Saved examples, duplicated collections and generated requests are snapshots of something else and drift from their source unless a link or a regeneration step keeps them aligned. - **Headless means explicit.** Every move from the app to a runner or a schedule turns an implicit choice into a flag, a file or a missing value.
explore
- Postman144 questions
- Collection Document23 questions
- Variable Stores23 questions
- Sandbox Scripts16 questions
- Verifying a Reply14 questions
- Cross-Request Flow12 questions
- Batch Execution13 questions
- Auth Helpers12 questions
- Transport Settings18 questions
- The Vendor's Side13 questions
- Newman5 questions
- SoapUI3 questions
questions
152 · 3 sectionsIn a Postman test script, what does `pm.response.to.have.status(200)` assert, and what else can `status` take?
basics
~20 sPostman'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.
In a saved Postman collection, where may an `auth` block be declared, and which declaration signs a request?
basics
~20 sThe 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.
In a saved Postman collection, how does the `auth` object name a scheme and where do its settings live?
basics
~10 sThe 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.
In a saved Postman collection file, what does a request's body.mode field select, and where does the payload sit?
basics
~10 sbody.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.
In a saved Postman collection file, what makes an entry in `item` a folder rather than a request?
basics
~10 sA 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.
What does the command `newman run collection.json` do, and how does it relate to `newman.run` in Node?
basics
~20 snewman run <collection> is the CLI's single command: it takes a collection as a path or URL, executes it, and reports through the cli reporter. Its action just builds options and calls newman.run(options, callback) — the same runner.
What makes a `newman run` process exit non-zero, and what does the `-x` flag change?
basics
~20 sThe Newman CLI sets process.exitCode to 1 when the callback receives an error, when the summary carries a run error, or when the summary's failures list is non-empty. The -x / --suppress-exit-code flag skips that assignment, leaving the code 0.
Which reporters ship with Newman's `-r` option, and how does it resolve a name that is not built in?
basics
~10 sNewman ships five reporters: cli, json, junit, progress and emojitrain. Any other name given to -r is required as the package newman-reporter-<name>, so -r html loads newman-reporter-html; a scoped name becomes @scope/newman-reporter-name.
In a Newman command line, what does `--bail` change about how a collection run proceeds?
basics
~20 sA bare --bail, or --bail failure, makes Newman turn on the runtime's stopOnFailure option, which ends the whole run at the first failure instead of continuing through the remaining requests. It does not change the exit code.
Why does adding `-r junit` to a Newman command silence the terminal, and where does the XML land?
basics
~20 sNewman's reporters option defaults to a list holding cli, and supplying a value replaces that default, so cli never loads. A reporter given no export path writes under a newman directory, its default name carrying a timestamp.
In SoapUI, what follows from requests being generated from a machine-readable service description rather than typed by hand?
basics
~20 sSoapUI derives its requests from the service's own machine-readable description, so the description rather than a person's memory decides which operations appear and what each call is shaped like. The price is staleness once that description moves on.
What does keeping SoapUI requests together as a suite give you that loose one-off calls do not?
basics
~20 sA suite turns calls from an activity into an asset: the requests and the checks that judge their answers are kept together, so the same set can be re-run later by someone who was not there the first time.
In SoapUI, what does standing the described service up as a stand-in prove, and what does it not?
basics
~20 sA stand-in derived from the same description as the requests proves your own side can form and handle the exchange, deterministically and without the real dependency. It never proves the deployed service behaves the way that description claims.