The install snippets ship placeholder versions

Both dependency snippets carry a placeholder

The getting started section says no additional configuration is needed and then shows two dependency declarations that cannot be pasted into a build. The Maven example ends with:

   <dependency>
      <groupId>org.springdoc</groupId>
      <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
      <version>last-release-version</version>
   </dependency>

and the Gradle example is:

implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:latest'

The version element is the literal text last-release-version, and the Gradle coordinate ends in a dynamic :latest rather than a number. Both are instructions to go and look the version up, which for a library whose whole purpose is to remove hand-maintained specification is an odd place to leave the work. The coordinates themselves are the useful part, since the group is org.springdoc and the artifact is the webmvc UI starter.

The custom path example sets the value it already has

The endpoints are documented precisely. The Swagger UI page is served at http://server:port/context-path/swagger-ui.html, with server, port and context-path each defined, and the OpenAPI description is available in JSON at /v3/api-docs and in YAML at /v3/api-docs.yaml. Then the file describes an optional step for a custom path for the swagger documentation in HTML format, and the configuration it shows is:

# swagger-ui custom path
springdoc.swagger-ui.path=/swagger-ui.html

The property is being set to the same value the previous paragraph already gave as the default location. So the one worked example of customisation in the file is a no-op, which leaves a reader who wants the UI somewhere else with the property name and nothing else. The YAML path is mentioned in passing in the same section, with no property shown for it.

The description is inferred from a running application

The mechanism is stated in three clauses and it matters for what the output can promise. springdoc-openapi works by examining an application at runtime to infer API semantics based on Spring configurations, class structure and various annotations. So the document is produced from the wiring the application actually has, not from a static reading of the source and not from a spec you maintain. From that flow the supported list follows: OpenAPI 3, Spring-boot v4 with Java 17 and Jakarta EE 9, JSR-303 with the file naming @NotNull, @Min, @Max and @Size specifically, Swagger-ui, OAuth 2, and GraalVM native images. The generated documentation can then be complemented with swagger-api annotations, which is the escape hatch for the cases where inference gets the semantics wrong. The table of contents names five further topics that this page does not show, and they are the ones that decide whether the output matches your service: error handling for REST with @ControllerAdvice, adding API information and security documentation, WebFlux support with annotated controllers, running the documentation on a separate management port, and what happens when Spring Security is enabled.

Two releases one second apart, and a title with commas

The release history shows what a lockstep versioning policy looks like in practice. The two most recent tags are v3.1.1 and v2.9.1, both created on 2026-09-06 and one second apart, so a maintenance line and a current line were cut in the same operation. Before them sits v3.1.0 from 2026-08-01, and its release title is written as springdoc-openapi v3,1,0 released, with commas where the tag has dots. That is a small thing, but it means the release titles are not generated from the version, so anything scraping them gets a string that does not parse. The policy itself is stated plainly: the project follows Semantic Versioning, MAJOR increments are released in lockstep with Spring Boot MAJOR releases and may include incompatible or breaking changes, and MINOR and PATCH follow the usual conventions, with CHANGELOG.md holding the full history.

One demo is linked by raw IP address

The demo list is mostly a set of named hosts. Six of the seven links point at demos1.springdoc.org, covering Web MVC with OpenAPI 3, WebFlux, WebFlux with functional endpoints, Spring Cloud Function Web MVC, and Spring Cloud Gateway, each with its own path. One does not. The demo titled Spring Boot 4 and Spring Cloud Function WebFlux is linked as:

http://158.101.191.70:8085/swagger-ui.html

A bare address, plain HTTP, a high port, no hostname. So the demo list gives two different answers to where these examples live, and the one that is least convenient is also the one that cannot survive a change of hosting without the link being updated by hand. The demo source code is a separate repository, springdoc-openapi-demos, on a 4.x branch, which is the more durable reference if you want to see how any of them is wired.

The module tree carries starters the overview never names

The top level of the repository is a matrix, and reading it tells you more than the feature list does. There is a springdoc-openapi-bom, a starter-common, and then two stacks, webmvc and webflux, each with four artifacts: an api starter, a ui starter, an mcp starter and a scalar starter. That is eight stack-specific modules plus the two common ones, a tests module, and the parent pom. So there are three ways to expose a UI, swagger-ui, Scalar, or no UI at all with the api starter alone, and there is a Model Context Protocol surface for both stacks. Neither MCP nor Scalar appears anywhere in the visible feature list or the getting started instructions, which name only OpenAPI 3, Spring-boot v4, JSR-303, Swagger-ui, OAuth 2 and GraalVM native images. The naming convention also explains the difference between springdoc-openapi-ui and the artifact in the dependency snippet, and the presence of a BOM next to them is the part that pays off at scale: importing it lets a multi-module build align every starter on one version instead of repeating coordinates.

A community project with a springdoc name

The introduction contains a sentence that exists to prevent a wrong assumption: this is a community-based project, not maintained by the Spring Framework Contributors (Pivotal). Given the group id org.springdoc and the name of the repository, that is worth reading before you file an issue against Spring itself or expect a support path from Broadcom. The project is on Open Collective, asks for sponsorship, and lists five commercial sponsors in the header, among them Mercedes-Benz, Contrast Security, LVM and GD Next. Security issues do not go to the issue tracker: the file points at the Tidelift security contact and says Tidelift will coordinate the fix and disclosure, and the header carries a Snyk badge alongside a SonarCloud dashboard.

Two contents anchors still say Spring Boot 3

The table of contents was updated for Spring Boot 4 and the anchors were not. One entry is labelled Integration of the library in a Spring Boot 4.x project without the swagger-ui and points at an anchor containing integration-of-the-library-in-a-spring-boot-3x-project-without-the-swagger-ui. Another is labelled Using a separate management port (Spring Boot 4) and points at using-a-separate-management-port-spring-boot-3. In both cases the visible heading text has moved to 4 while the fragment it links to still carries the 3, so those two links land on nothing. It is the kind of leftover that survives a major-version migration because nothing validates anchors, and it is a useful signal about how much else in the file moved from 3.x to 4.x. Two of the table-of-contents entries carry bold labels, Introduction and Getting Started, while the rest are plain, which suggests the list was edited in two passes. The build badge at the top points at a self-hosted Jenkins on port 8443 rather than a hosted CI service.

Editorial conclusion

This library is the reasonable choice for a Spring Boot service that needs an OpenAPI description without maintaining a spec by hand, and runtime inference means the description matches the wiring you actually shipped. Four things to check before you adopt it. Which artifact you need, since the tree carries API, UI, MCP and Scalar starters for both webmvc and webflux and only some are named in the README. Which major line matches your Spring Boot, because MAJOR versions move in lockstep with Spring Boot and may break. Which UI you want, since Scalar appears only in the module tree. And how you pin the dependency, because neither documented snippet gives you a resolvable version.

Frequently asked questions

Official sources

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