DEV Community

Cover image for Free Open-Source CLI Tools for Development
Hassann
Hassann

Posted on • Originally published at apidog.com

Free Open-Source CLI Tools for Development

Most developer workflows still run through the terminal. The tools that remain useful for years usually have one thing in common: they are open source. You can inspect the code, self-host server components, avoid seat licenses and “contact sales” gates, and fork a project if maintenance slows down. For API and backend work, that ownership matters.

Try Apidog today

This is a practical list of free, genuinely open-source CLI tools for day-to-day API development and backend work. Every entry has a permissive or copyleft license, public source code, and no cost to run. The selection criteria are license and lock-in—not startup speed or GitHub star count.

You will get seven tools for the core API loop:

  • Send HTTP requests
  • Parse JSON responses
  • Test HTTP flows in CI
  • Automate GitHub work
  • Expose local services for webhook testing
  • Version API artifacts

Each section includes the license, repository, and a command you can run immediately. There is also a clearly labeled note about where a free-tier commercial tool can fit.

What qualifies as an open-source CLI tool?

A tool being free to download is not enough. Some tools are closed source, while others expose a core project but put important features behind a paid service.

For this list, a tool must pass three checks:

  1. Use an OSI-approved license. MIT, Apache 2.0, BSD, and GPL licenses allow you to inspect, use, modify, and redistribute the software under their terms.
  2. Publish source code publicly. You should be able to read the code, review issues, inspect releases, and assess maintenance.
  3. Avoid mandatory lock-in. The tool should not require an account, unavoidable telemetry, or a hosted service you cannot replace or self-host.

Stars and commit frequency are useful signals, but they are secondary. Always inspect the repository’s LICENSE file before standardizing on a tool.

curl: the universal HTTP client

curl is the baseline HTTP tool. It supports dozens of protocols, ships with many operating systems, and has been maintained continuously since 1996. It uses the permissive curl license, an MIT/X derivative.

curl logo

Use it when portability matters. If a machine can run shell scripts, it can usually run curl.

curl -s -X POST https://api.github.com/repos/curl/curl/issues \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test issue","body":"Filed from curl"}'
Enter fullscreen mode Exit fullscreen mode

For reusable scripts, separate the request body from the command:

cat > issue.json <<'JSON'
{
  "title": "Test issue",
  "body": "Filed from curl"
}
JSON

curl -sS -X POST https://api.github.com/repos/curl/curl/issues \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data @issue.json
Enter fullscreen mode Exit fullscreen mode

Best for: portable requests and shell automation.

Limit: verbose syntax and unformatted JSON output. Pair it with jq when you need to read or transform responses.

HTTPie: readable requests and responses

HTTPie is an HTTP client optimized for interactive use. Its requests are concise, JSON request bodies are the default, and response output is formatted for humans. It is licensed under BSD-3-Clause.

Install it with pip:

pip install httpie
Enter fullscreen mode Exit fullscreen mode

Send a JSON request:

http POST httpbin.org/post name=apidog role=platform
Enter fullscreen mode Exit fullscreen mode

The name=apidog and role=platform arguments become JSON fields automatically. HTTPie also prints headers, status, and a pretty-formatted body without an additional command.

Add an authentication header when debugging an API:

http GET https://api.github.com/user \
  Authorization:"Bearer $TOKEN"
Enter fullscreen mode Exit fullscreen mode

Best for: manually exploring and debugging APIs.

Limit: it is a Python package, so it is heavier than a standalone binary. For minimal CI images, curl is often still the better fit.

jq: JSON processing for shell pipelines

APIs return JSON. jq is the command-line processor that lets you filter, reshape, validate, and extract JSON in a pipeline. It is MIT licensed.

Fetch repository metadata and select only the fields you need:

curl -s https://api.github.com/repos/jqlang/jq \
  | jq '{name: .name, stars: .stargazers_count, license: .license.spdx_id}'
Enter fullscreen mode Exit fullscreen mode

Example output:

{
  "name": "jq",
  "stars": 0,
  "license": "MIT"
}
Enter fullscreen mode Exit fullscreen mode

Use -r when you need raw text instead of JSON strings:

curl -s https://api.github.com/repos/jqlang/jq \
  | jq -r '.default_branch'
Enter fullscreen mode Exit fullscreen mode

Use -e in CI when a missing value should fail the command:

curl -s https://api.github.com/repos/jqlang/jq \
  | jq -e '.license.spdx_id == "MIT"'
Enter fullscreen mode Exit fullscreen mode

Best for: turning large JSON payloads into exactly the data the next script step needs.

Limit: its syntax is terse. Start with field access, object construction, arrays, and select() before attempting complex transformations.

gh: the GitHub CLI

GitHub CLI (gh) brings pull requests, issues, releases, Actions, and GitHub API calls into the terminal. It is written in Go and MIT licensed.

Authenticate once:

gh auth login
Enter fullscreen mode Exit fullscreen mode

Then use gh api instead of manually managing GitHub tokens in every curl command:

gh api repos/cli/cli/releases --jq '.[0].tag_name'
Enter fullscreen mode Exit fullscreen mode

That prints the latest release tag. You can also use the API endpoint in scripts:

gh api repos/cli/cli/issues \
  -f title="Test issue" \
  -f body="Filed from gh"
Enter fullscreen mode Exit fullscreen mode

Best for: GitHub automation, release workflows, and repository maintenance.

Limit: it is GitHub-specific. Use another platform’s CLI—or plain HTTP requests—for GitLab, Gitea, and other forges.

Hurl: commit HTTP tests as plain text

Hurl runs HTTP requests defined in text files and asserts on status codes, headers, and JSON responses. It is written in Rust and Apache 2.0 licensed.

Create repo.hurl:

GET https://api.github.com/repos/Orange-OpenSource/hurl

HTTP 200
[Asserts]
jsonpath "$.name" == "hurl"
jsonpath "$.stargazers_count" > 1000
Enter fullscreen mode Exit fullscreen mode

Run it:

hurl --test repo.hurl
Enter fullscreen mode Exit fullscreen mode

Hurl exits with code 0 when every assertion passes and a non-zero code when one fails, so it fits naturally into CI jobs.

You can capture a value from one request and reuse it later:

GET https://api.example.com/login

HTTP 200
[Captures]
token: jsonpath "$.token"

GET https://api.example.com/profile
Authorization: Bearer {{token}}

HTTP 200
Enter fullscreen mode Exit fullscreen mode

Best for: readable, version-controlled integration tests.

Limit: Hurl focuses on HTTP request/response testing. It is not a full contract-testing or load-testing platform. For a spec-first API development workflow, keep your OpenAPI definition as the source of truth and use Hurl for executable checks.

cloudflared: expose a local service with a public URL

When testing webhooks, mobile clients, or demos, you often need to expose a local API to the public internet. cloudflared is Cloudflare’s open-source tunnel client. Its quick-tunnel mode provides a temporary *.trycloudflare.com URL without requiring an account. It is Apache 2.0 licensed.

Run a local service:

npm run dev
Enter fullscreen mode Exit fullscreen mode

Expose port 3000:

cloudflared tunnel --url http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

The command prints an HTTPS URL that forwards requests to localhost:3000 until you stop the process.

Use that generated URL as a webhook callback target during local testing.

If you prefer an npm-based option, localtunnel is MIT licensed:

npx localtunnel --port 3000
Enter fullscreen mode Exit fullscreen mode

Best for: fast, ad-hoc public tunnels.

Limit: quick-tunnel URLs are random and temporary. Stable named tunnels require a Cloudflare account and configuration, even though the client remains open source.

git: version API artifacts from the terminal

git is command-line version control first. Your OpenAPI documents, Hurl files, shell scripts, and CI configuration should live in a repository. git is GPLv2 licensed.

A useful implementation pattern is running API tests before commits.

Create a local pre-commit hook:

echo 'hurl --test *.hurl' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
Enter fullscreen mode Exit fullscreen mode

Now each commit runs the matching Hurl tests first. If a test fails, git blocks the commit.

For a project-level hook that the whole team can share, commit hooks into the repository and configure git to use them:

mkdir -p .githooks
printf '%s\n' '#!/usr/bin/env sh' 'hurl --test tests/*.hurl' > .githooks/pre-commit
chmod +x .githooks/pre-commit

git config core.hooksPath .githooks
Enter fullscreen mode Exit fullscreen mode

Best for: versioning the API workflow that every other tool depends on.

Limit: git is version control, not project hosting. GitHub, GitLab, and Gitea are separate hosting choices.

An honest aside: where Apidog fits

Apidog is not open source, so it is not an OSS entry in this list. It is a commercial product with a free tier.

The open-source tools above work well independently, but you assemble the workflow yourself:

  • curl or HTTPie for requests
  • jq for response parsing
  • Hurl for HTTP tests
  • A separate mock server
  • A documentation generator
  • Shell-managed environment variables

Apidog combines design, testing, mocking, and documentation in one workspace. Its apidog-cli package brings those workflows into the terminal:

npm install -g apidog-cli
Enter fullscreen mode Exit fullscreen mode

The CLI can run test scenarios, manage endpoints and schemas, configure mock expectations, and import or export OpenAPI definitions. It produces structured JSON output suitable for scripts and AI agents. Like Hurl, apidog run exits with 0 on success and non-zero on failure, which makes it usable in CI.

The trade-off is straightforward:

  • Choose the open-source toolkit when you need full source access and control over the plumbing.
  • Choose an integrated platform when reducing tool integration work is more important than source access.

If you choose the CLI route, follow the installation guide for authentication and first commands.

How to choose

Use tools together instead of treating them as replacements:

curl -s https://api.example.com/users \
  | jq '.[] | select(.active == true) | .email'
Enter fullscreen mode Exit fullscreen mode

A practical baseline stack looks like this:

Tool Best for Install Open source? Notes
curl Portable requests and scripting Usually preinstalled Yes, curl/MIT-style Available almost everywhere
HTTPie Human-friendly debugging pip install httpie Yes, BSD-3-Clause Colorized output and JSON defaults
jq Parsing JSON responses Package manager or binary Yes, MIT Pipeline glue
gh Automating GitHub Package manager or binary Yes, MIT GitHub-only by design
Hurl Committable HTTP tests Single binary Yes, Apache 2.0 Non-zero exit code on test failure
cloudflared Public local tunnels Single binary Yes, Apache 2.0 Quick tunnels require no account
git Version control Usually preinstalled Yes, GPLv2 Foundation for the rest
apidog-cli Integrated API workflow npm i -g apidog-cli No, free tier available Design, test, mock, and docs

Rule of thumb: use single-purpose open-source tools when you want to own the plumbing. Use an integrated platform when maintaining that plumbing becomes overhead. For the integrated option, see the overview of Apidog as a comprehensive API development platform.

Wrapping up

Open-source CLI tools earn a place in the terminal because they are inspectable, forkable, and resistant to lock-in.

Start with a small stack:

  1. Use curl or HTTPie to call APIs.
  2. Add jq to process JSON.
  3. Commit Hurl tests alongside your API code.
  4. Use git hooks or CI to run those tests automatically.
  5. Add gh and cloudflared when GitHub automation or webhook testing becomes necessary.

curl, HTTPie, jq, gh, Hurl, cloudflared, and git cover the core API and backend workflow without requiring a proprietary platform.

For agent-driven automation, structured JSON output becomes the bridge between terminal tools. Read more about AI coding assistants for API development. If managing separate tools starts to become its own maintenance task, download Apidog and evaluate the Apidog CLI workflow before committing to either approach.

Top comments (0)