APIAuto: an HTTP interface tool that treats test cases as a database-backed workflow

One browser tool for docs, tests, mocking and debugging

APIAuto is a JavaScript project whose default branch is `master`, built around a plain web front end rather than a desktop shell. The README describes a tool that collects documentation, testing, mocking, debugging and management in one place, and adds AI question answering plus keyboard shortcuts for formatting and toggling comments.

The method coverage is broad and conventional: GET, POST, PUT, PATCH, DELETE and HEAD, with Content-Type selection and URL paths written as `/{Path}/{Variable}`. The README says this works for RESTful APIs, REST-like APIs and gRPC, and names Tencent's APIJSON project as the one case where Tencent officially recommends it for documentation and testing. The topic list on the repository agrees with that framing, tagging it for api-testing, apitesting, autotesting, http-client, grpc, headless and documentation-tool.

What the README does not do is tell you how to start it. Its navigation points outward instead: DeepWiki for the English version and for AI question answering, a bilibili video tutorial series, and a hosted online instance at apijson.cn/api. That is a reasonable choice for a project with a large Chinese-language user base, and it means the English reader's first real stop is not GitHub.

The adoption claims are specific rather than vague. Internally the README names Tencent business groups including IEG, TEG and CSIG, and externally it names Huawei, a regional branch of Industrial and Commercial Bank of China, Transsion, SHEIN and a social insurance technology vendor. It also lists a long set of internal and conference talks, including appearances at the QECon software quality conference.

What the machine learning no-code testing claim actually covers

The signature feature is called machine learning no-code testing. The mechanism shows up in the release notes more clearly than in the README, which is the honest place to look. Version 4.0.0, published 2024-12-12, added a validation model with a `format` parameter for asserting string formats, so you can assert a date looks like `YYMM-MM-DD` or a string looks like `http://a.b`. The same release added a `guess: true` parameter that infers the likely type of a null value from the field name, and a `notempty` parameter for deciding whether empty is allowed as a string, empty object or non-positive number.

The user-facing consequence of that model is a diagnostic affordance rather than a pass or fail badge. Version 4.0.0 put a checkmark and error icon on JSON keys, with the specific assertion problem shown on hover, and began showing the Response Body directly whenever HTTP Status Code was not 200. Time and timestamp fields are ignored by the zero-code assertion, which is sensible but worth knowing if you assert on a field with those names.

Version 6.0.0, published 2026-07-13, tightened the same area rather than adding a new category: dropdown options for HTTP Method and Content-Type, more complete TEXT, XML and HTML parameter types, a fix for `multipart/form-data`, and assertions for empty values and formats that previously failed to report correctly.

Set expectations correctly here. This is learned validation of response shape, ordering and type, which catches the class of regressions where a field quietly changes from a string to null. It is not a substitute for asserting business invariants, and the README does not document how the validation model was trained or how to inspect its decisions beyond the hover text.

Parameter injection, the feature that actually differs from Postman

If one capability justifies a switch from Postman, it is parameter injection. Version 6.0.0 added shortcut configurations for database reads and writes, `DB_SELECT`, `DB_INSERT`, `DB_UPDATE` and `DB_DELETE`, plus various HTTP request configurations and compatibility with custom expressions.

The mechanism is straightforward once you see it: a query pulls a value out of a real table and injects it into the request body, so the case does not carry a frozen JSON literal. Version 5.0.0 extended this so that `RANDOM_DB` and `ORDER_DB` accept a custom request body and a `schema.table` form, which means you can point the injection at a non-default database rather than being stuck with one. The same release added `ORDER_IN('a', 'bc')` for generating request headers, and fixed `getValByPath` so it can take values in reverse order, alongside a fix for `setValByPath` occasionally reporting `undefined`.

That is the concrete difference in approach. Postman collections are documents you maintain by hand, so a renamed column or a changed enum becomes a failing test somebody has to repair. A case driven from the schema keeps referring to the current shape. The cost is that you now have a database dependency inside your test layer, and the 6.0.0 notes show that dependency needs its own maintenance, since one release had to add `RANDOM_DB` and `ORDER_DB` deduplication for arrays and fix cases where the wrong JSON was used.

For anyone comparing tools, that is the axis to compare on. Mock servers, request history and environment variables are table stakes; sourcing test values from the schema under test is not.

Scenario chaining, custom tags and the CI problem

Multi-step flows arrived in version 4.0.0, which added support for chaining several interfaces into a scenario case, with the README-level example being a home page, product, cart and checkout sequence. Version 5.0.0 then added automatic generation of parameter passing configuration for scenario cases, and fixed two bugs that matter for anyone running shared accounts in CI: regression scenario chaining and switching accounts while viewing results had mismatched cases and accounts.

Case management also grew up. Version 4.0.0 added automatic grouping by URL prefix, with multi-level directory-style filtering, and automatic classification of create, read, update and delete endpoints. Version 5.0.0 added custom tags on cases with AND and OR quick filtering, bound test accounts to chained scenario cases, added `PRE_ARG` and `PRE_DATA` configuration with an auto-refreshing list, and improved `CTX_PUT` parameter passing.

The CI angle is where the Node side of the project shows up. Version 5.0.0 fixed problems running cases on the Node HTTP API in the background, specifically dependencies, progress calculation and script loading, and it also added configurable custom logout URLs. Version 6.0.0 fixed scenario chaining losing its `context`.

What the repository contains underneath is a small Node service rather than an Electron app. The package is named `apijson-api-auto`, described as the APIAuto headless regression server, marked private, with a single start script and a Koa stack:

  "scripts": {
    "start": "node js/server.js"
  },

  "dependencies": {
    "axios": "^1.14.0",
    "json5": "^2.2.3",
    "koa": "^3.2.0",
    "koa-bodyparser": "^4.4.1",
    "page-agent": "^1.10.0"
  },

`page-agent` is the dependency behind the 6.0.0 headline feature, an AI agent that operates the web page itself, described in the release as automatic web page operation. It is worth understanding before you enable it, because automating the browser interface is a different trust boundary from injecting values into a request. Note also that the package version is `1.0.0` while the releases are numbered 6.0.0, 5.0.0 and 4.0.0, so the npm-style version in `package.json` does not track the product version in the releases.

Generated code, exported docs and hover comments

Documentation output is the other half of the tool. Version 6.0.0 improved Markdown export of cases, with better response results and comments. Earlier, version 5.0.0 added the AI question answering and English documentation, crediting the DeepWiki developers and Devin AI, and introduced a cursor-hover behaviour that scans a data dictionary after one second and explains the field, including splitting `user_id` into `user.id` before looking up the comment.

Code generation is the part that has been narrowing over time. Version 4.0.0 added intelligent generation of Python assertion code using the machine learning validation model, and made the generated Python cases include assertion functions. In the same release, Objective-C support was removed. That direction is worth reading as a decision: the project is converging on Python as its generated target and letting other languages go.

For a team, the practical question is which of these outputs you actually consume. If your reviewers read a generated Markdown file, the export improvements matter. If you paste cases into a Python test suite, the assertion generation matters. If you want the hover comment inside your editor, note that it depends on the tool's own web interface rather than your IDE, even though the README mentions floating hints alongside code generation.

The README is honest about the comparison it invites. It claims APIAuto goes beyond Postman, Swagger and YApi on common functions and can import cases and documentation in one click. The difference in approach against those three is that Postman and YApi are collection and documentation stores that you maintain, while APIAuto tries to derive both from live requests and a database, with the AI layer assisting rather than replacing the record.

Licence metadata, maintenance signals and what to verify

There is a licence question here that you should resolve yourself rather than assume. The repository metadata reports the project as Apache-2.0, and the README's badge row and content do not contradict that directly. But `package.json` in the repository declares `"license": "ISC"`. Those two statements disagree, and neither is self-evidently the one that governs: the GitHub licence field is repository metadata, the package field describes the private headless server package, and the `LICENSE` file in the tree is the document that would settle it for code you copy.

The practical resolution is to read the `LICENSE` file directly and treat the two metadata fields as unverified. Since the package is marked `"private": true` and is not published, the ISC string in `package.json` most likely describes the small server wrapper rather than the project, but that is an inference, not something the repository states. Do not build a compliance answer on either field without opening the file.

On maintenance, the signals are strong. The default branch is `master`, the last push was on 2026-09-03, and the release cadence is unusually productive for a small project: version 4.0.0 in December 2024, then 5.0.0 on 2026-06-01 and 6.0.0 on 2026-07-13, with each release carrying a detailed changelog instead of a commit list. The topic list includes `vuejs2`, which dates the front end stack, and the repository has 66 open issues against 274 forks, a ratio that suggests real usage with room for the backlog to grow.

What the repository does not show is a test suite of its own. The tree contains `bootstrap/`, `css/`, `img/`, `js/`, `md/` and `svg/` alongside `index.html`, plus two stray files worth noticing: `debug.log` and `webon.log.json`. Those are committed log artefacts rather than documentation, and their presence tells you the project is developed by committing real output. For an evaluation, check three things yourself: whether a Python-only generated target fits your stack, whether your endpoints are covered by the method and Content-Type dropdowns, and what the LICENSE file actually grants.

Editorial conclusion

APIAuto is genuinely different from Postman in one narrow way: parameter injection pulls values straight from a database into a request and an assertion, so cases track schema changes instead of going stale as hand-copied JSON. Everything else on offer, request history, environments, docs, is familiar territory, and the README is explicit that Tencent recommends it for APIJSON. Before adopting it, resolve the licence question by reading the LICENSE file in the repository rather than the package metadata, and confirm your team can live with the fact that the local run path is a private Node package started with `node js/server.js`. If your API is served from gRPC rather than HTTP, verify support for your specific method and content type before you build a suite on it.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. TommyLemon/APIAuto on GitHub