Best Open Source API Testing Tools for CI

There is no single best open source API testing tool, and the question that separates them is not the interface but what each one runs inside a pipeline. Seven projects answer that clearly: Bruno, Hoppscotch, Hurl, Karate, Schemathesis, Step CI and DevTools, which is our own tool and is labelled as such below. Every entry gives the same four things: the license, the file a test lives in, the exact command CI runs along with the flag that writes a report, and the date of the most recent release. One of the seven sells paid editions above its open core. One has not shipped a release since June 2024.

How these tools were picked

Almost every result on the first page for this query is a roundup written by somebody else: a Reddit thread, a vendor blog, a listicle counting to ten or to fifteen. Google's own summary sorts the same names by interface, a privacy-first desktop client here, a code-based automation framework there. None of them prints the command your pipeline will run.

So this list answers four questions about every tool, in the same order, from each project's own documentation:

1. License. What the repository reports, and whether paid editions sit above it.
2. What CI runs. The command, and the flag that writes a machine-readable report.
3. Where the test lives. The file format, and whether one changed request reads as a diff in a pull request.
4. Last release. The tag and date of the most recent release, checked on 13 September 2026.

The second question is the one that decides most adoptions, and it is the one a listicle almost never answers. A tool earns its place in a pipeline by turning a suite into an exit code and a report file your CI already knows how to display. Everything upstream of that, the interface, the syntax, the assertion style, is a preference your team can argue about later. If the answer to "what does CI run" is a wrapper script somebody on the team wrote, you have picked a client, not a test runner.

The license question needs one distinction the roundups skip. An open-source runner is not the same thing as an open-source product. Kong's Insomnia repository and Postman's Newman runner both carry Apache-2.0. A repository badge tells you what you may copy, not what you get to keep using. Bruno states the same split from the other side, saying most of its features are free and open source and pointing at paid versions for teams that want more. Neither fact is a criticism. It is the difference between a tool you can run and a tool you can keep.

Bruno

Bruno is the client that put the collection back in the repository. Its repository says it uses a plain text markup language, Bru, to save information about API requests, so a collection is a folder of text files sitting beside the code it tests, and one changed header is one changed line in review. Google's summary calls it a strictly offline-first, Git-friendly API client.

The runner is bru. A collection runs with bru run, and the flag that matters in CI is --reporter-junit [string], documented as the path to generate a JUnit report, with --reporter-html [string] for an HTML report. The Bruno CLI docs put the choice plainly: reports in multiple formats, including JSON, JUnit, and HTML.

License is MIT. Above it sits the paid tier described in the criteria section. Read that feature list before you standardize a team on the free edition.

Latest release: v4.1.0 on 20 August 2026, with the repository pushed to on 11 September 2026.

Hoppscotch

Hoppscotch runs in a browser, and its docs describe the authoring loop as clicking: create a collection with the "Add new" button in the collections section and name it, then export it with the "Export" button and pick the type you want. That is the straight answer to the no-GUI question. The interface writes the collection; the command line runs it.

The runner is hopp. The documented call is hopp test <file_path_or_id> --env <file_path_or_id> --reporter-junit [path], and the CLI docs state that the hopp test command now has the ability to generate a JUnit Report for collection runs in the CLI. The same page frames the CLI as the way to drive Hoppscotch from a terminal or an automated system.

Because the CLI takes a collection file as its argument, the exported file is the unit of review. A folder of per-request files gives a reviewer a smaller diff; one exported collection gives them one document to read.

License is MIT, the latest release is 2026.8.0 on 28 August 2026, and the repository was pushed to on 12 September 2026.

Hurl

Hurl is the smallest thing here that still counts as a test suite. Its own description: a command line tool that runs HTTP requests defined in a simple plain text format. It chains requests and captures values out of responses.

Reporting is where it earns a place in a pipeline. The testing docs give --test for test output, --report-junit FILE for JUnit, --report-tap FILE for a Test Anything Protocol report, and --report-html DIR for HTML. A CI job that already reads JUnit needs one flag; a job whose runner speaks TAP needs a different one, and both are in the binary.

Where the test lives is the plain text file itself, which is as reviewable as a suite gets: the request, the assertions and the captures are the file.

License is Apache-2.0, the latest release is 8.0.1 on 29 April 2026, and the repository was pushed to on 12 September 2026. Releases are spaced out; the work behind them is not.

Karate

Karate calls itself the open-source tool that combines API testing, mocks, performance testing, and UI automation into a single, unified framework, under an MIT license.

Its scripts are plain text, require no compilation step or IDE, and let teams collaborate using Git or standard source control, and the syntax follows the Cucumber and Gherkin standard closely enough that, in the project's words, Java knowledge is not required and even non-programmers can write tests. Karate walks subdirectories looking for *.feature files.

The price of entry is the runtime. Karate requires at least Java 17 and then either Maven, Gradle, or a Java IDE that embeds one of them, and the command line suite runs with mvn test. If the service under test is already a JVM project, that costs nothing. If it is a Go binary or a Node service, you have added a build toolchain to the pipeline for the sake of the tests: a JDK to install, a dependency cache to warm, and a build file to keep current. Karate pays that back in reach, since the same framework covers API tests, mocks and performance work. The trade reads differently for a team already standardized on the JVM than for one that is not.

Latest release: v2.1.2 on 14 August 2026, with a push on 13 September 2026.

Schemathesis

Schemathesis is the one entry that does not replay requests a person wrote. It generates property-based tests from your OpenAPI or GraphQL schema, chains operations into realistic workflows, and exercises the edge cases that break your API.

That reshapes the storage question. There is no authored request file to review, so what your repository holds is the schema and the CI configuration, and a pull request that changes the schema changes the tests by definition.

The documented invocation is uvx schemathesis run https://example.schemathesis.io/openapi.json. In CI, --report junit writes the JUnit XML, and the CI guide calls the project's GitHub Action the simplest integration path. The project sums up its own surface as CLI, pytest, GitHub Actions, plus Allure, JUnit XML, and HAR output.

License is MIT, and the latest release is v4.27.0 on 12 September 2026, the day before this post was written.

Step CI

Step CI is in every roundup and nowhere near a release. Its repository calls it an open-source API Quality Assurance framework, says the source code is distributed under Mozilla Public License terms, runs a workflow with stepci run workflow.yml, and accepts workflows written in YAML, JSON or JavaScript. On paper it fits this list well: one command, a text workflow, no interface in the way.

Then the dates. The most recent release is 2.8.2, published on 10 June 2024, and the last push to the repository was 3 August 2024. The repository is not archived, so nothing on the page warns a reader, and the roundups go on listing it beside projects that shipped last month.

A dormant dependency is not an emergency, it is a deferred cost. The suite keeps passing until a runtime upgrade, a TLS change or a transitive security advisory lands, and at that point the fix is yours to write or yours to migrate away from, on whatever week it happens. Weigh that against how many tests you plan to move into it.

Keep it if you already run it and nothing is broken. Do not start a new suite on it without deciding who maintains the fork.

DevTools (our own tool)

Full disclosure: DevTools is our tool, built by the team publishing this post. It is here because it answers the same four questions, and every claim below comes from our own documentation.

Our docs state that DevTools is open source under the Apache-2.0 license and free to use. The product chains multi-step requests into reusable YAML workflows, records real traffic, auto-maps variables between steps, and runs end-to-end API tests in CI with parallel execution and JUnit reports.

A test lives in a YAML flow file in your repository: the CI guide's first step is exporting a flow to YAML, saving it as api-tests.yaml, and committing it. The CLI is stateless by default, reading flows from the working directory, writing reports to files or stdout, and running in CI with no persistent storage at all.

The command is devtools flow run <yamlflow-file> [flow-name], with --report junit:results.xml for CI systems, and the exit codes are 0 when every flow succeeded, 1 when one or more failed, and 2 for a configuration or setup error. The documented GitHub Actions step runs devtools flow run api-tests.yaml --report junit:test-results.xml --report json:test-results.json.

Latest release: cli@1.1.1 on 9 August 2026, with a push on 7 September 2026.

The same four answers, side by side

Every cell below is quoted from the project's own docs or read from its repository on 13 September 2026. Where a column is blank, the documentation read for this post did not state it.

Read the table by column instead of by row. The license column splits permissive from copyleft. The CI command column splits one binary from a build toolchain. The release column is the one the roundups never print.

Questions teams ask before they commit

Which of these can I use without ever opening a GUI?

Hurl, Karate, Schemathesis and Step CI. Hurl runs HTTP requests defined in a simple plain text format, Karate's scripts are plain text and need no IDE, Schemathesis builds its cases from your schema, and Step CI runs a YAML workflow from one command. Bruno and Hoppscotch expect the client for authoring; Hoppscotch's docs describe creating a collection by clicking "Add new" and naming it.

Which open source API testing tools produce a JUnit report?

Five of the seven document a JUnit flag: Bruno with --reporter-junit, Hoppscotch with --reporter-junit, Hurl with --report-junit FILE, Schemathesis with --report junit, and DevTools with --report junit:results.xml. For Karate and Step CI, the documentation read for this post did not state a JUnit report path, so confirm it before a pipeline depends on it.

Is Step CI still maintained?

Its most recent release is 2.8.2 from 10 June 2024, its last push was 3 August 2024, and the repository is still not marked archived. Treat it as dormant: fine to keep running, risky to build something new on.

What is the closest fully open source answer to Postman?

It depends which half of Postman you are replacing. For the client, Bruno's MIT repository and plain text collections are the nearest match. For running existing Postman collections in CI, Newman is Apache-2.0 and lives in Postman's own GitHub organization.

Which is better, Bruno or Postman?

For a team whose test changes arrive as pull requests, Bruno's storage answer decides it: requests are saved in plain text files.

Picking one

Start from the pipeline, not the interface. If your CI already reads JUnit XML, five of these seven hand it one with a documented flag, and the choice narrows to where you want tests authored: in a client, in a plain text file, or nowhere at all because a schema generates them. If your service is a JVM project, Karate's requirement is free; if it is not, that requirement is the decision. And check the release date of anything a roundup recommends before you commit a suite to it, because a list that never prints one will happily put a project dormant since 2024 next to one that shipped yesterday.