Best lightweight CLI tools for API testing

Most API testing tools want you to open a window, sign in, and click around a workspace before you can send a single request. That’s fine for a first look. It’s the wrong shape for the terminal, where you want to type one line, read the response, and move on. Lightweight command-line tools flip the order: the tool gets out of the way, and the request is the whole interaction.

Lightweight here means something specific. A small install, often a single binary or a quick npx. Fast startup, so hitting an endpoint feels instant. Little or no config to run the first request. Terminal-first output you can pipe into jq or grep. This is a different question from “which tool is open source” or “which has the most features.” It’s about footprint and friction. For a broader survey that also covers hosted GUIs, see the best free API testing tools roundup.

Below are eight lightweight CLI tools for testing REST and HTTP APIs, ordered roughly from smallest and most manual to the ones that run full test suites in CI. Each entry has a real install command, one command that shows it working, what it’s best at, and an honest limit. The last one, the Apidog CLI, is the lightweight binary that runs the scenarios you build visually and gates a pipeline on its exit code.

What makes a CLI tool “lightweight” for API testing

Plenty of tools run in a terminal. Not all of them feel light. For this list, a tool qualifies on four points:

• Small footprint. A single binary, a pip/npm install, or an npx one-liner. No runtime you have to set up first, ideally no daemon.
• Fast startup. The tool launches and sends the request without a warm-up. Rust and Go binaries win here; anything that boots a heavy runtime loses.
• Low or zero config. You can send the first request with no project file, no account, no login. Config is opt-in, for when you want to save and repeat.
• Terminal-native output. Results print in a form you can read at a glance and pipe into another command. Exit codes mean something, so CI can gate on them.

The tools lead with the first three; the last two lean on the fourth, because that’s where a lightweight binary earns its place in a pipeline. If you want the interactive, hit-an-endpoint-by-hand side in more depth, the curl alternatives for REST API testing guide goes deeper on the manual clients.

curl: the baseline that’s already installed

curl is the tool you almost certainly already have. It ships on macOS, most Linux distros, and modern Windows, so the lightest install is no install. It speaks HTTP, HTTPS, and a long list of other protocols, and it’s the reference every other client measures itself against.

# Already on your machine; check the version
curl --version

# POST JSON and print only the HTTP status
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"user":"acme","plan":"pro"}'

Best for: quick one-off requests, scripts, and any environment where you can’t install anything new. Honest limit: the ergonomics are dated. You set headers by hand, JSON isn’t pretty-printed, and asserting on a response means piping into jq and checking an exit code yourself. It sends and shows; it doesn’t test.

HTTPie: curl for humans

HTTPie makes the same requests curl does, with syntax built for people. The command is http, headers and JSON fields are simple key=value pairs, and the output is colorized and formatted by default. It’s written in Python, so it needs a Python runtime, which makes it heavier than a single binary but still a one-line install.

python -m pip install httpie   # or: brew install httpie

# POST JSON: age:=24 sends a number, name= sends a string
http POST httpbin.org/post name=acme age:=24 plan=pro

Best for: exploring an API by hand when you want readable output without flags. Honest limit: the Python startup is noticeably slower than a compiled binary, and installing into a clean system means pulling in Python if it isn’t there. Like curl, it’s a client, not a test runner; you read the response, you don’t assert on it.

xh: HTTPie’s speed in a single binary

xh reimplements HTTPie’s friendly syntax in Rust and ships as one statically linked binary. You get the same key=value ergonomics and colored output, with faster startup and nothing to install beyond the binary itself. It supports HTTP/2 and can even print the equivalent curl command with --curl.

brew install xh   # or: cargo install xh --locked

# Same syntax as HTTPie, faster start
xh POST httpbin.org/post name=acme age:=24 plan=pro

Best for: developers who like the HTTPie feel but want a single fast binary with no runtime. Honest limit: it doesn’t implement every HTTPie feature, and there’s no plugin system. It’s younger than HTTPie, so the ecosystem around it is smaller. Still a client, not an assertion engine.

Hurl: plain-text tests that run in CI

Hurl is where this list crosses from “send a request” to “test a response.” It runs HTTP requests written in a plain-text .hurl file and asserts on the results. It’s written in Rust, powered by libcurl under the hood, and ships as a single binary with no runtime. Tests read almost like the requests themselves, which makes them easy to review in a pull request.

brew install hurl   # or: cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://httpbin.org/post
{ "user": "acme", "plan": "pro" }

HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
EOF

hurl --test login.hurl   # non-zero exit if an assertion fails

Best for: contract-style checks and smoke tests you keep in version control as readable text. The --test flag makes it a clean CI gate; a failed assertion returns a non-zero exit code. Honest limit: it’s HTTP-focused, so it won’t drive gRPC or generate real load. Complex flows mean more .hurl files rather than a scripting language.

Step CI: one YAML file for a multi-step flow

Step CI runs API workflows described in a single YAML file. It covers REST, GraphQL, gRPC, tRPC, and SOAP in one workflow, and it can validate against an OpenAPI schema. You install it from npm and run the same file locally and in CI. It reads well when a test is really a sequence: log in, capture a token, use it on the next call, check the result.

npm install -g stepci

# workflow.yml describes steps, captures, and checks
stepci run workflow.yml

Best for: teams that want one declarative file describing a multi-step API flow, run identically on a laptop and in a pipeline. Honest limit: it’s a Node package, so it’s heavier than a Rust or Go binary, and it carries a runtime. Release cadence has slowed, so check the repo’s recent activity before you build a pipeline on it. For how these pieces fit a fuller test plan, see API testing strategies.

k6: lightweight load testing from the terminal

k6 answers a different question: not “is this response correct” but “does it hold up under load.” It’s written in Go, ships as a single static binary, and scripts are plain JavaScript. It’s built for minimal resource use, so you can push real traffic from a laptop. Thresholds turn a load test into a pass/fail gate; breach one and k6 exits with code 99, which a pipeline reads as a failure.

brew install k6   # or run via Docker: docker run grafana/k6

cat > load.js <<'EOF'
import http from 'k6/http';
import { check } from 'k6';
export const options = {
  vus: 10, duration: '30s',
  thresholds: { http_req_duration: ['p(95)<500'] },
};
export default function () {
  const res = http.get('https://httpbin.org/get');
  check(res, { 'status is 200': (r) => r.status === 200 });
}
EOF

k6 run load.js

Best for: performance and load checks you want to script and run in CI without standing up a cluster. Honest limit: it’s a load tool, not a functional test client; you wouldn’t reach for it to eyeball a single response. Writing meaningful scenarios means learning its JavaScript API.

Newman: run a Postman collection headless

Newman is the command-line runner for Postman collections. If your team already builds requests and tests in Postman, Newman runs that exact collection from a terminal with no GUI, which is what you need in CI. You export the collection (and optionally an environment) as JSON and point Newman at it.

npm install -g newman

# collection.json exported from Postman; -e passes an environment
newman run collection.json -e staging.json

Best for: teams invested in Postman who want their existing collections to run headless in a pipeline. Newman returns a non-zero exit code when a test fails, so it gates CI cleanly. Honest limit: it’s a Node package, and it only runs Postman-format collections, so it’s most useful if you’re already in that ecosystem. It runs tests someone built in a GUI; the authoring still happens there.

Apidog CLI: run the scenarios you built, gate CI on the exit code

The Apidog CLI is the lightweight end of Apidog. It’s an npm package, apidog-cli, that runs the test scenarios you designed visually in Apidog straight from a terminal. The build-a-test part stays in the GUI, where chaining requests, extracting variables, and writing assertions is fast; the CLI is the small piece that runs one of those scenarios headless and hands you an exit code. Apidog isn’t open source, but its free tier plus this CLI gives you an integrated alternative to stitching a separate client, runner, and load tool together.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# Copy the exact command from your scenario's CI/CD tab
apidog run -t <scenario_id> -e <env_id> -r cli

You don’t guess the scenario and environment IDs. Open your test scenario in Apidog, go to the CI/CD tab, and copy the generated apidog run command with the IDs already filled in. The -r cli reporter prints a step-by-step result and a summary in the terminal; add -r cli,junit when a CI dashboard needs to parse the results. Like the tools above, apidog run exits 0 when every assertion passes and non-zero when anything fails, so a pipeline treats it as a clean gate. Its output is structured JSON with agentHints.nextSteps, which makes it easy for an AI coding agent to run and read too.

Best for: teams that want to author complex, multi-step scenarios in a visual editor but run them headless in CI or from an agent. Honest limit: unlike curl or xh, it’s tied to scenarios you keep in an Apidog project, so it’s the integrated-platform option, not a bare HTTP client. For the full command set, see the Apidog CLI complete guide, the apidog run command reference, and the walkthrough on how to test a REST API from the command line with the Apidog CLI.

How to choose

The right tool depends on how far past “send one request” you need to go.

Start at the top for manual work. Reach for curl or xh to poke an endpoint. Drop to Hurl when you want those checks to run in version control. Bring in k6 when the question turns to load, and Newman if your tests already live in Postman. Pick the Apidog CLI when you’d rather build a complex scenario in an editor and run it headless everywhere else. If you’re weighing these against a full GUI-free workflow, the headless API testing tool guide covers running tests without any interface at all.

Where lightweight tools pay off

Lightweight CLI tools win on the same days a GUI slows you down: when you’re deep in a terminal, when a test needs to run in CI without a human, and increasingly when an AI agent runs the check for you. curl and xh keep the manual loop tight. Hurl and Step CI turn ad-hoc requests into repeatable tests. k6 answers the load question. Newman runs what you already built in Postman.

The Apidog CLI closes the gap between building a test and running it anywhere. You design the scenario once in Apidog, then apidog run fires it from a terminal, a pipeline, or an agent, and the exit code decides whether the build stays green. Download Apidog, build one scenario, and drop its apidog run command into your CI config to see the whole loop close.