Free Open-Source CLI Tools for API Testing

Most API testing tutorials point you at a GUI. But if you live in the terminal, run tests in CI, or want a tool you can read the source of, the command line is where API testing gets interesting. Open-source CLI tools give you something a hosted product can’t: a license you can audit, a binary you can self-host, and a config file you can commit next to your code.

This is a different question from “what’s the fastest tool” or “what’s the smallest binary.” Here the lens is licensing and control. Can you run it inside your own network with no account? Is the source on GitHub under a real OSI-approved license? Will it keep working if the vendor changes pricing next quarter? Those are the questions this list answers.

Below are eight free, source-available CLI tools for testing REST, GraphQL, and HTTP APIs, each with its exact license, a real install command, and one command that shows it working. If you want a broader survey that includes hosted tools, see the best free API testing tools roundup. For a purely terminal-first take on hitting endpoints by hand, the curl alternatives for REST API testing guide covers the interactive side.

What makes a CLI tool “open source” for API testing

Plenty of tools are free to download. That’s not the same as open source. For this list, a tool qualifies on three points:

• A real license. The source is public under an OSI-approved license (MIT, Apache-2.0, MPL-2.0, AGPL-3.0, BSD). You can read it, fork it, and know what you’re allowed to do.
• Self-hostable, no account. You can run the whole thing on your own machine or CI runner without signing up for anything. No seat cost, no phone-home requirement.
• Maintained and inspectable. The repo is on GitHub with visible commit history and issues, so you can judge whether it’s alive before you build a pipeline on it.

Every tool below meets the first two. I’ve flagged the one that no longer meets the third. License choice matters more than it looks: AGPL-3.0 (k6) has copyleft obligations if you build a service around it, while MIT and Apache-2.0 are permissive. Read the license before you embed a tool in a product.

Hurl: plain-text HTTP tests, one Rust binary

Hurl runs HTTP requests written in a plain-text format and asserts on the responses. It’s built by Orange-OpenSource in Rust, powered by libcurl under the hood, and shipped as a single binary. Tests read almost like the requests themselves, which makes them easy to review in a pull request.

License: Apache-2.0. Source: github.com/Orange-OpenSource/hurl.

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

# login.hurl
cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }

HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF

hurl --test login.hurl

Best for: contract-style checks and smoke tests you want to keep in version control as readable text. Honest limit: it’s HTTP-focused, so it won’t drive gRPC or generate load. For anything beyond simple assertion chains you’ll write more .hurl files rather than reach for a scripting language.

Step CI: YAML API workflows built for CI

Step CI is a YAML-configured workflow runner made for continuous integration. It covers REST, GraphQL, gRPC, tRPC, and SOAP in a single workflow file, and it can load-test and validate against an OpenAPI schema. The runner and CLI are free forever.

License: MPL-2.0. Source: github.com/stepci/stepci.

npm install -g stepci

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

Best for: teams that want one declarative file describing a multi-step API flow and running it the same way locally and in CI. Honest limit: MPL-2.0 is a weak copyleft, so if you modify Step CI’s own files you share those changes back. Using it to test your app carries no such obligation.

Schemathesis: property-based testing from your schema

Schemathesis reads your OpenAPI or GraphQL schema and generates thousands of test cases from it, using property-based testing built on Python’s Hypothesis library. Instead of you writing each case, it fuzzes inputs to find 500s, schema violations, and responses that don’t match what your docs promise.

License: MIT. Source: github.com/schemathesis/schemathesis.

uv pip install schemathesis   # or: pip install schemathesis

schemathesis run https://api.example.com/openapi.json

Best for: catching edge-case bugs you’d never think to write a test for, especially before a release. It’s one of the strongest reasons to keep an accurate schema. Honest limit: it needs a real schema to work, and a large API can produce a lot of noise you’ll want to filter with its hooks and options.

Dredd: contract testing against your API description

Dredd checks that your live API actually matches its description document. Point it at an OpenAPI (or API Blueprint) file and a running backend, and it replays every documented request and compares the real response to the spec. It’s language-agnostic and supports hooks for setup and teardown.

License: MIT. Source: github.com/apiaryio/dredd.

npm install -g dredd

dredd apiary.apib http://127.0.0.1:3000

Best for: proving your documentation and your implementation haven’t drifted apart. Honest limit, and it’s a real one: the Dredd repository was archived in November 2024 and is read-only. It still runs, but it’s no longer maintained, so treat it as a stable tool with no future fixes. If you want an actively maintained schema-driven checker, Schemathesis is the safer bet.

k6: load testing scripted in JavaScript

k6 is Grafana’s load and performance testing tool. You script tests in JavaScript or TypeScript, and a fast Go engine drives them at scale. It’s the go-to open-source option when you need to know how your API behaves under hundreds or thousands of virtual users, not just whether a single request passes.

License: AGPL-3.0. Source: github.com/grafana/k6.

brew install k6

k6 new script.js   # generates a starter test
k6 run script.js

Best for: performance and soak testing that lives in the same repo as your functional tests. Honest limit: AGPL-3.0 is strong copyleft. That’s fine for running tests, but if you build and distribute a service around k6’s code, the license has real obligations; read it first. k6 also focuses on load, not fine-grained contract assertions.

Newman: run Postman collections without the GUI

Newman is Postman’s own command-line collection runner. If your team already has API requests and tests saved as a Postman collection, Newman runs that exact collection from the terminal or in CI, no desktop app required. It’s the standard way to get a Postman workflow into a pipeline.

License: Apache-2.0. Source: github.com/postmanlabs/newman.

npm install -g newman

newman run my-collection.json -e staging-environment.json

Best for: teams with existing Postman collections who want CI runs without paying for extra Postman seats. Honest limit: it’s tied to the Postman collection format, so you author tests in Postman’s UI (or its JSON) rather than in a plain config file. It runs collections; it doesn’t design or mock APIs.

Tavern: API tests as a pytest plugin

Tavern is a Python library, CLI, and pytest plugin that describes API tests in YAML. Because it plugs into pytest, you get the whole pytest ecosystem for free: fixtures, reporting, parallelism, and CI integrations you may already use. It handles REST, MQTT, and gRPC.

License: MIT. Source: github.com/taverntesting/tavern.

pip install tavern

# test_login.tavern.yaml sits next to your other tests
pytest test_login.tavern.yaml

Best for: Python shops that already run pytest and want API tests to live right alongside unit tests. Honest limit: it assumes you’re comfortable in a Python testing setup. If your stack isn’t Python, the pytest dependency is friction rather than a feature.

Venom: multi-executor integration tests from OVHcloud

Venom, from OVHcloud, runs integration tests across many executor types: HTTP requests, shell scripts, IMAP, web, databases, and more. It’s written in Go, uses YAML test suites, and emits xUnit result files that CI systems read natively. It shines when a single test needs to touch more than just an HTTP endpoint.

License: BSD (modified). Source: github.com/ovh/venom.

# download the binary from GitHub releases, then:
venom run testsuite.yml

Best for: end-to-end flows that mix an API call with a database check or a script step in one test suite. Honest limit: with so many executors, the YAML gets verbose, and the docs assume you’ll piece together examples from the repo.

Where Apidog fits (and an honest note)

Here’s the honest part. Apidog is not open source. It’s a commercial product with a free tier, so it doesn’t belong on a list of source-available tools. But it’s worth knowing about for one reason: the tools above each do one job, and stitching Hurl plus Schemathesis plus Newman plus a mock server into a coherent workflow is real work you have to maintain yourself.

Apidog folds design, testing, mocking, and documentation into one platform, and apidog-cli brings the testing side to the terminal. You author test scenarios once, then run them in CI with a single command:

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token <TOKEN>   # exits 0 on all-pass, non-zero on failure

The output is structured JSON with agentHints.nextSteps, which makes it easy to script or hand to an AI agent. The complete apidog-cli guide walks through the full command set. So: not open source, but the free tier plus CLI gives you an integrated alternative to wiring several single-purpose tools together. If a license you can audit is a hard requirement, pick from the eight above. If an integrated workflow matters more, this is the trade.

How to choose

Match the tool to the job. Reach for Hurl or Newman when you want fast, readable request checks; Schemathesis when you have a schema and want bugs found for you; k6 when the question is scale; Tavern or Venom when tests need to live in a larger suite. If you’re weighing these against a bigger process, the API testing strategies guide covers where each type fits, and the headless API testing tool piece looks at running tests with no UI at all.

Wrapping up

Open-source CLI tools give you API testing you can read, fork, and run on your own terms. Hurl and Newman handle everyday request checks, Schemathesis and Dredd enforce your contract, k6 pushes on performance, and Tavern and Venom fold API tests into wider suites. Pick by license and by the one job you need done; nothing stops you running two of them.

When you’d rather design, test, mock, and document in one place instead of maintaining a toolchain, Apidog covers the full lifecycle and ships apidog-cli for CI. Download Apidog to try the CLI alongside the tools above and see which mix fits your pipeline.