https://github.com/OpenAPITools/openapi-generator
You can also have an LLM generate a client from an OpenAPI spec
In MCP Apps: Extending servers with interactive user interfacesOpenAPITools
openapi-generator
Java2018–2025
OpenAPITools / openapi-generator
openapi-generator
OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
43Distinct people
101Mentions
0Explicit recommenders
26.9KGitHub stars
What to know before exploring
What it is
OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- swagger-api/swagger-codegen · linked in 3 of the same discussions
- azure/autorest · linked in 2 of the same discussions
- go-swagger/go-swagger · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year101 dated mentions
Observed mentions: 2018-06-02 02:49:00 UTC to 2025-11-24 00:55:21 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 10 | 5 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 35 | 25 | 10 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 15 | 6 | 9 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 12 | 4 | 8 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 0 | 4 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
OpenAPI Generator
Master (7.28.0):
⭐⭐⭐ If you would like to contribute, please refer to guidelines and a list of open tasks. ⭐⭐⭐
‼️ To migrate from Swagger Codegen to OpenAPI Generator, please refer to the migration guide ‼️
📔 For more information, please refer to the Wiki page and FAQ 📔
📔 The eBook A Beginner's Guide to Code Generation for REST APIs is a good starting point for beginners 📔
⚠️ If the OpenAPI spec, templates or any input (e.g. options, environment variables) is obtained from an untrusted source or environment, please make sure you've reviewed these inputs before using OpenAPI Generator to generate the API client, server stub or documentation to avoid potential security issues (e.g. code injection). For security vulnerabilities, please contact team@openapitools.org. ⚠️
‼️ Both "OpenAPI Tools" (https://OpenAPITools.org - the parent organization of OpenAPI Generator) and "OpenAPI Generator" are not affiliated with OpenAPI Initiative (OAI) ‼️
Sponsors
If you find OpenAPI Generator useful for work, please consider asking your company to support this Open Source project by becoming a sponsor. You can also individually sponsor the project by becoming a backer.
Thank you to our bronze sponsors!
Thank you GoDaddy for sponsoring the domain names, Linode for sponsoring the VPS, Checkly for sponsoring the API monitoring and Gradle for sponsoring Develocity
Overview
OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (both 2.0 and 3.0 are supported). Currently, the following languages/frameworks are supported:
Languages/Frameworks
API clients
ActionScript, Ada, Apex, Bash, C, C# (.net 2.0, 3.5 or later, .NET Standard 1.3 - 2.1, .NET Core 3.1, .NET 5.0. Libraries: RestSharp, GenericHost, HttpClient), C++ (Arduino, cpp-restsdk, Qt5, Tizen, Unreal Engine 4), Clojure, Crystal, Dart, Elixir, Elm, Eiffel, Erlang, Go, Groovy, Haskell (http-client, Servant), Java (Apache HttpClient 4.x, Apache HttpClient 5.x, Jersey2.x, OkHttp, Retrofit1.x, Retrofit2.x, Feign, RestTemplate, RESTEasy, Vertx, Google API Client Library for Java, Rest-assured, Spring 5 Web Client, Spring 6 RestClient, MicroProfile Rest Client, Helidon), Jetbrains HTTP Client, Julia, k6, Kotlin, Lua, N4JS, Nim, Node.js/JavaScript (ES5, ES6, AngularJS with Google Closure Compiler annotations, Flow types, Apollo GraphQL DataStore), Objective-C, OCaml, Perl, PHP, PowerShell, Python, R, Ruby, Rust (hyper, reqwest, rust-server), Scala (akka, http4s, scalaz, sttp, swagger-async-httpclient, pekko), Swift (2.x, 3.x, 4.x, 5.x, 6.x), Typescript (AngularJS, Angular (9.x - 19.x), Aurelia, Axios, Fetch, Inversify, jQuery, Nestjs, Node, redux-query, Rxjs), XoJo, Zapier
Server stubs
Ada, C# (ASP.NET Core, Azure Functions), C++ (Httplib, Oat++, Pistache, Restbed, Qt5 QHTTPEngine), Erlang, F# (Giraffe), Go (net/http, Gin, Echo), Haskell (Servant, Yesod), Java (MSF4J, Spring, Undertow, JAX-RS: CDI, CXF, Inflector, Jersey, RestEasy, Play Framework, PKMST, Vert.x, Apache Camel, Helidon), Julia, Kotlin (Spring Boot, Ktor, Vert.x), PHP (Flight, Laravel, Lumen, Mezzio (fka Zend Expressive), Slim, Silex, Symfony), Python (FastAPI, Flask), NodeJS, Ruby (Sinatra, Rails5), Rust (rust-server), Scala (Akka, Finch, Lagom, Play, Cask, Scalatra)
API documentation generators
HTML, Confluence Wiki, Asciidoc, Markdown, PlantUML
Configuration files
Apache2
Others
GraphQL, JMeter, Ktorm, MySQL Schema, Postman Collection, Protocol Buffer, WSDL
Table of contents
Sponsors
Thank you to our bronze sponsors!
Thank you GoDaddy for sponsoring the domain names, Linode for sponsoring the VPS, Checkly for sponsoring the API monitoring and Gradle for sponsoring Develocity
Overview
Table of contents
1 - Installation
1.1 - Compatibility
1.2 - Artifacts on Maven Central
1.3 - Download JAR
Launcher Script
1.4 - Build Projects
Nix users
1.5 - Homebrew
1.6 - Docker
Public Pre-built Docker images
OpenAPI Generator CLI Docker Image
OpenAPI Generator Online Docker Image
Development in docker
Troubleshooting
Run Docker in Vagrant
1.7 - NPM
1.8 - pip
2 - Getting Started
3 - Usage
To generate a sample client library
3.1 - Customization
3.2 - Workflow Integration (Maven, Gradle, Github, CI/CD)
3.3 - Online OpenAPI generator
3.4 - License information on Generated Code
3.5 - IDE Integration
4 - Companies/Projects using OpenAPI Generator
5 - Presentations/Videos/Tutorials/Books
6 - About Us
6.1 - OpenAPI Generator Core Team
Core Team Members
Template Creator
How to join the core team
6.2 - OpenAPI Generator Technical Committee
Members of Technical Committee
6.3 - History of OpenAPI Generator
Founding Members (alphabetical order):
7 - License
1 - Installation
1.1 - Compatibility
The OpenAPI Specification has undergone 3 revisions since initial creation in 2010. The openapi-generator project has the following compatibilities with the OpenAPI Specification:
OpenAPI Generator Version
Release Date
Notes
7.28.0 (upcoming minor release) SNAPSHOT
20.11.2026
Minor release with breaking changes (with fallback)
7.27.0 (latest stable release)
02.11.2026
Minor release with breaking changes (with fallback)
6.6.0
11.05.2023
Minor release with breaking changes (with fallback)
5.4.0
31.01.2022
Minor release with breaking changes (with fallback)
4.3.1
06.05.2020
Patch release (enhancements, bug fixes, etc)
OpenAPI Spec compatibility: 1.0, 1.1, 1.2, 2.0, 3.0, 3.1 (beta support)
(We do not publish daily/nightly build. Please use SNAPSHOT instead)
For old releases, please refer to the Release page.
For decommissioned generators/libraries/frameworks, please refer to the "Decommission" label in the pull request page.
1.2 - Artifacts on Maven Central
You can find our released artifacts on maven central:
Core:
<dependency>
<groupId>org.openapitools</groupId>
<artifactId>o
Read the full README on GitHubWhat Hacker News says
101 sources> Ideally I'd like to be able to write types in typescript, and write python types, then verify that the types are compatible (not identical)
Have a look at https://fastapi.tiangolo.com/
FastAPI allows you to define your types in Python using Pydantic for stronger type guarantees. FastAPI also generates an OpenAPI.json file for your backend and then you can feed this OpenAPI.json document into https://github.com/OpenAPITools/openapi-generator to generate a typescript library that contains all the types. Then you don't need to verify your types, because the typescript types will be directly generated from your Python types. The generated typescript library also contains methods for each of your REST endpoints, so that you don't have to think about network requests.
In A Rust-TypeScript integrationIt would be great if D supported something like OpenAPI generator https://github.com/OpenAPITools/openapi-generator
Maybe it exists and I am just ignorant but it doesn't seem to be in the list of supported languages.
In Programming in D: Tutorial and ReferenceI'm also really happy with spec first. We're using openapi-generator[1] to generate types from a yaml schema (inverting the more standard approach of generating the yaml) in our Typescript (mostly Nest.js) backends, and export those types as packages for use in our frontends.
[1] https://github.com/OpenAPITools/openapi-generator
In Show HN: FastOpenAPI – automated docs for many Python frameworksDid you try to use https://github.com/OpenAPITools/openapi-generator directly?
In After 3 Years, I Failed. Here's All My Startup's CodeThere's a huge number of them https://openapi.tools/#sdk
Including the semi official tools https://github.com/OpenAPITools/openapi-generator
Now if you want multi language generation and especially high quality you may have to spend a lot of time evaluating different choices. I decided that the official java client didn't generate very nice python code and went with https://github.com/openapi-generators/openapi-python-client even though it's a small personal project with a primary developer+random contributions from users. It just seemed nicer to use for python. Finding which generator to use especially for JavaScript seems difficult
In After 3 Years, I Failed. Here's All My Startup's Codehttps://github.com/OpenAPITools/openapi-generator has 22K stars
In After 3 Years, I Failed. Here's All My Startup's CodeWhich tricks do you use to write less code?
I found some "tricks" to write less code, hence less code to maintain if there are any changes. Also less code with bugs just by changing the inputs.
For example, OpenAPI spec file + OpenAPI generator (https://github.com/OpenAPITools/openapi-generator). Any changes in the OpenAPI spec are reflected in the final code with a build step.
Another example: MapStruct (https://mapstruct.org/) to avoid passing data from Entity classes to DTO and back. Saves looots of boilerplate code.
I don't have much to say for frontend as I am mainly working on backend. So good to know your stuff.
Which are your tricks?
2 points · Open discussionThat one only does Go, but it is just one of many OpenAPI generators. I used openapi-generator and was able to produce SDKs for TypeScript (angular and node), Dart (Flutter), Kotlin (andoird), and Swift (iOS). They worked great for our purposes and I really had no complaints or issues.
I guess my question is, what is the key differentiator that Stainless offers above just using OpenAPI and its huge library of existing generators?
https://github.com/OpenAPITools/openapi-generator
In The Stainless SDK GeneratorI helped maintain the public API language bindings at Stripe for many years, and although I'd defend it to the death as the right DX (SDKs are so much easier to use than raw web APIs), it's hard to appreciate just how onerous of a process this was before Alex pioneered a codegen-based solution.
Some of the language SDKs were dynamic (e.g. Ruby, Python) and could adapt automatically to small API changes like if a new field was added in a response. Some were not (e.g. Java, Go), and for every API change, someone had to manually make the change to that SDK's codebase (add a field, add a struct, add a function for a new endpoint), get it reviewed and merged, and cut a release. As Stripe got bigger and there were API changes all the time, the only way this was even remotely functional was that we had a couple heroic workhorses that'd watch for
Read the rest
changes and open hundreds of PRs a year for them. Honestly, in retrospect, it's amazing this even worked.
Getting everything switched over to a generated solution was an arduous process because the new generated code had to be API-compatible with the existing code so that the cutover to generated bindings didn't break every Stripe user under the sun. We eventually got there, but it took a long time.
I like Stainless' mission because after seeing the crazy maintenance hassle that all of this was at Stripe, I think it makes way more sense to save all that engineering time for your more concerns, and outsource this problem to someone else. A plug-and-play way of getting high quality SDKs in all common languages that get pushed to appropriate repositories for distribution and comes with quality companion documentation.
We've actually had pretty good luck at my current job with open source tools like openapi-generator [1], but this sort of codegen is so convoluted that the sustainability of a pure open source solution makes me a little afraid, and you still end up doing a lot of the last mile work yourself.
---
[1] https://github.com/OpenAPITools/openapi-generator
Disclaimer: We're an early adopter of Stainless at Mux.
I've spent more of my time than I'd like to admit managing both OpenAPi spec files [1] and fighting with openapi-generator [2] than any sane person should have to. While it's great having the freedom to change the templates an thus generated SDKs you get with using that sort of approach, it's also super time consuming, and when you have a lot of SDKs (we have 6 generated SDKs), in my experience it needs someone devoted to managing the process, staying up with template changes etc.
Excited to see more SDK languages come to Stainless!
[1] https://www.mux.com/blog/an-adventure-in-openapi-v3-api-code...
[2] https://github.com/OpenAPITools/openapi-generator
In The Stainless SDK GeneratorThere are open source generators for a ton of languages[1]! We've been reasonably happy with their output for ~5 SDKs over the last few years. We did a massive writeup on our experience at the time[2].
In the end...ongoing maintenance there was still enough of a pain that we made the decision to outsource it. For just one or two SDKs I think we probably would have kept going with it, though.
[1] https://github.com/OpenAPITools/openapi-generator
[2] https://www.mux.com/blog/an-adventure-in-openapi-v3-api-code...
In The Stainless SDK GeneratorOf course you can compile the server from source if you have Go and the OpenAPI generator JAR (https://github.com/OpenAPITools/openapi-generator?tab=readme...)
Follow these steps : https://github.com/c100k/rebootx-on-prem/blob/master/.github...
And then :
(cd ./impl/http-server-go && GOARCH=amd64 GOOS=openbsd go build -o rebootx-on-prem-http-server-go-openbsd-amd64 -v)
By adapting the arch if needed. Not tested, but it should work.
In Show HN: Manage on-prem servers from my smartphoneOpenAPI Generator v7.3.0 has new generators for Rust, Kotlin, Scala and Java
2 points · Open discussionA metaprogramming technique like source-code generation is not a serious issue in any design. It's especially helpful if the source of truth in your design is external to the current code base. You can generate:
- documentation from source-code files, some CLI frameworks are offering this (eg. oclif[0])
- types from schema files, and schemas from types (eg. quicktype[1])
- API clients and servers from specifications (eg. openapi-generator[2])
...these are all repetitive tasks that can be automated.
That being said, I wouldn't personally generate it in the build step, but rather introduce an additional generate step for it and sync the generated output with the VCS of choice. I recently wrote about it a bit here[3].
[0]: https://github.com/oclif/oclif#oclif-readme
[1]: https://app.quicktype.io/
[2]: https://github.com/OpenAPITools/openapi-
Read the rest
Showing the 15 most recent of 101 sources. Enable JavaScript to search and browse every indexed mention.