XXL-API keeps the API catalogue, the mock server and the tests in one place

One platform for three roles that usually work from different documents

The introduction describes XXL-API as an API management platform that is easy to learn and use, simple and efficient and powerful in functionality, and it names the roles it serves as product, front-end and back-end development and testing. That list is the design brief. In most teams the API lives in three places at once, a document for the humans, a mock for the frontend to code against, and a collection of test scripts, and the three drift apart. This platform puts them together, with one-stop capabilities covering API management, mock and testing. The onboarding claim is that it takes three minutes to get going, which is a typical claim for a tool of this kind and worth checking against the deployment reality, but the intent is clear, that the catalogue is a tool rather than a document.

Projects and groups are the two levels of organisation

Two of the eleven listed features are about structure. The first is project isolation, supporting the isolation and control of APIs along the project dimension, which is the answer to a simple problem, that a shared list of endpoints across a company stops being useful once there is more than one team. The second is group management, where within a single project the APIs can be put into custom groups, so the structure can be finer than the project without duplicating projects. The third level is the business line, which appears in the permission model, and that gives three levels in total, a business line owns projects, a project owns groups, and a group holds the API definitions. The readme also mentions a star marking feature, where an API can be starred so that it is displayed with priority, which is a small signal of how much content a single project can accumulate.

Permissions are granted per business line, not per API

The fifth feature is the one with a real design opinion in it. Permission control is supported along the business line dimension, so a user's rights are attached to a business line rather than to individual endpoints, and a user is only allowed to operate the projects and the data types under a business line once the permission has been assigned. The stated purpose is to keep the API data safe. The trade is the usual one, since permissions at that level are cheap to administer but coarse, so a user with a business line permission sees everything in it, and the readme does not describe a finer mechanism for exceptions. For a small team that granularity is not needed, and for a larger one the business line has to be drawn along lines that match how the organisation actually divides its work, which is a modelling exercise the tool cannot do for you.

The mock server and the test tool are the same product

The sixth and seventh features are what separate this from a catalogue. The API mock feature is built in, with a MockServer that lets you define mock data for an API flexibly and customise the format of the response, and the stated purpose is to provide mock interfaces quickly and speed up development. The API testing feature allows online testing of an API and lets you define and manage test data, which is described as improving interface testing efficiency. The two features share the catalogue, which is the point, because a mock derived from the real API definition is a mock that matches the contract, and a test case that runs against the same definition is a test that stays honest. It also means the definition of an API is the thing you maintain, with the mock and the test derived from it, rather than three artefacts maintained in parallel.

The attribute model is the real schema of an API

The ninth feature lists the properties an API entry can carry, and the list is the data model of the product. There is the status, the request method, the request URL, the request headers, the request parameters, the response result, the format of that response, the parameters within it, and a note field. The eighth feature covers the ordinary lifecycle, creating, updating and deleting APIs. The eleventh adds Markdown formatted notes to an API, so the documentation that would otherwise live outside the tool can sit next to the definition. Taken together, the point is that an API in this platform is described completely enough to mock, to test and to hand to a consumer, which is the level of completeness that a Swagger file alone does not reach, since a specification says what the endpoint accepts and returns but not what the values are supposed to look like in practice.

Container images, a Maven build and a Java CI job

The second feature is the containerisation, with an official Docker image published and pushed to Docker Hub as the project is updated, and the promise is that the product works out of the box in that form. The README carries a badge for the Docker Hub pulls of the admin image, and a Java CI workflow badge, which tells you the build is Maven and the pipeline compiles it. The repository layout is small, with a `pom.xml` at the root, an `xxl-api-admin/` directory holding the web application, a `doc/` directory and an `AGENTS.md` for coding agents working on the tree. The documentation itself lives outside the repository, on the author's own site, with a Chinese documentation link and a community page, and there is a registration issue where companies that adopt it can sign up, which the readme is careful to say is only for product promotion.

Licence, community and the shape of the project

The licensing is straightforward, the GNU General Public License version 3, with the copyright held by the author from 2015 to the present, and the readme states that the product is open source and free, that free community technical support will continue, and that both individual and enterprise users may access and use it freely. There is also a donation page, and the readme's tone about it, that any amount is enough to express a thought, is a small and pleasant detail. The contribution model is the usual for a project of this size, a pull request to fix a bug or an issue to discuss a feature or a change, and the releases are numbered in a way that follows the feature list, with 1.7.1 in June 2026, 1.7.0 in December 2025 and 1.6.0 in October 2025, and the last push to the repository on 2026-10-09. What the project is not, and the readme does not claim it is, is a gateway. Nothing sits in the request path, and there is no rate limiting or routing, because the job here is describing, mocking and testing the API rather than serving it.

Editorial conclusion

XXL-API suits a team where the frontend developers are calling endpoints that the backend has not finished, since the mock server and the catalogue are the same product, and it suits a larger organisation where different business lines need to see different APIs. It is a poor fit if you want an open source gateway, since this is a management and testing platform rather than something that sits in the request path, and it is a poor fit if you need a specific feature beyond the eleven the readme lists, because the feature set is what it is. Before you deploy it, check three things: which database and configuration the container expects, since the readme does not walk through the deployment and points to the Chinese documentation for that, how you want to model your projects and business lines, since the permission model hangs off them, and the version, with 1.7.1 published on 2026-06-07 and the last push to the repository on 2026-10-09.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. xuxueli/xxl-api on GitHub