API teams struggle to keep OpenAPI usable across tools
Developers need to generate, update, filter, and consume OpenAPI specifications across different languages and tools, but the available integrations and generators don’t consistently support their required versions or produce reliable output. Teams fall back to manual authoring, custom scripts, or hand-importing specs. The signals point to a shared OpenAPI workflow problem, though the specific gaps vary substantially by framework and downstream tool.
For API developers and platform teams. Mentioned from Sep 2018 to May 2026 on Bluesky, GitHub, Hacker News and Stack Exchange.
23 different people described this problem in 19 separate discussions.
- Indie fit
- 6.0/10
- Pain
- 5.4/10
- Frequency
- 10.0/10
- Willingness to pay
- 2.0/10
- Momentum
- 5.0/10
- Who pays
- Businesses
- Competition
- High
- Build difficulty
- Medium
What people said
Quoted word for word. Follow a link to read the whole discussion.
Until today, I used the OpenAPI generator. But even its latest version 7.22.0 faces troubles, either with its rust_server or rest-axum generator, producing models whose structs or collections sometimes doesn't comply to a trait that a validator will refer later to
Tools that actually supported the current version (3.1), which is the only one that's acceptable because of glaring gaffes in previous specs. B. Code-generation tools that supported the languages we needed C. Code-generation tools that worked at all
Build brief
See what to build and who will buy it
- 2 product ideas with the smallest useful version and pricing
- 4 places to find your first customers
- 23 more quotes from people who have this problem
- Current workarounds, existing solutions and risks