openapi.tools: a curated directory of 300 plus OpenAPI tools, with the version filters doing the work

A curated index, not a catalogue of everything that exists

openapi.tools is a directory of more than 300 tools for working with OpenAPI descriptions. The categories the README lists are editors, linters, parsers, code generators, documentation, testing and mocking, and the site is described as the most comprehensive collection of quality OpenAPI tooling, curated by Phil Sturgeon and the team at APIs You Won't Hate.

The word curated does the work here. This is not a scraped index of every package with openapi in its description, it is a selection that somebody decided belongs on the list. That distinction matters both ways: the directory is more useful per entry than a raw search result, and it is smaller than the true ecosystem, so a tool that exists and is good can still be missing.

The project describes itself as community-maintained with regular contributions, and the contributing guide is in CONTRIBUTING.md at the root of the repository. The last push to the repository was on 2026-10-18 and it is not archived, so additions do arrive.

For a newcomer to OpenAPI tooling the interesting decision is not which tool to pick but which category the problem falls into, and the directory is organised around exactly that question.

Filtering by language and OpenAPI version is what the directory is for

The features list names the filters explicitly: tools are organised by category with filtering by language, by OpenAPI version support and by more criteria beyond that. Version support is the filter that matters most in practice, because the OpenAPI specification has moved through 3.0 and 3.1 and a tool that only understands one of them is not a near miss, it is a different tool.

The curated collections address the same problem from the other direction. You can browse open source tools, SaaS products, or legacy tools, and the legacy collection is described as the pre-3.1 ones. That separation is honest: a project that has not adopted 3.1 has not stopped being maintained, but it is solving an older problem, and lumping it in with 3.1 capable tools would misrepresent both.

A reader can also jump straight to a hosted product, which is the case where a team does not want to own the tool's runtime at all. The site separates open source from SaaS, and the sponsor model applies to both, so a badge is a signal about who paid rather than about the quality of the implementation.

If you arrive knowing the language you work in and the specification version you need, the filters reduce a 300 entry list to a short shortlist, and that is the whole workflow this site is built around.

Sponsorship buys placement, and the site says so

The funding model is stated plainly on the page. Openapi.tools is maintained by APIs You Won't Hate, and sponsorship helps cover costs and enable continued development. The benefits for sponsors are listed: priority placement in category listings, a Sponsored badge on the tool, and embeddable badges for your own website, with options at openapi.tools/badges and a sponsor page at openapi.tools/sponsor.

That is worth sitting with when you use the directory. A sponsored tool appears earlier in its category, and the badge is on the listing. Nothing about that is hidden, which is what makes it workable, but it does mean the ordering of results carries a commercial signal that has nothing to do with how good a tool is.

The alternative is a plain list you maintain yourself. That list has no bias at all, and it costs you the filter by language, the filter by OpenAPI version, the distinction between open source and SaaS, and the separation of pre-3.1 tooling. What you get in exchange is full control over what is in it, which is the reason some teams prefer it. The directory wins on discovery, the private list wins on independence.

The cost of running the site is real enough that sponsorship is a reasonable answer to it, and the site is explicit rather than coy about what sponsorship buys.

An Astro site with React components, Tailwind and Netlify

The tech stack is small and current. Astro is the static site generator, React provides the interactive components, Tailwind CSS handles styling, and Netlify hosts the result. The dependency list confirms the shape of a content site with a filtering UI: Radix UI primitives for checkbox, dialog, popover, scroll area and slot, cmdk for the command palette style search, @tanstack/react-table for the results table, framer-motion for animation, lucide-react for icons, date-fns for formatting, and tailwind-merge with clsx and class-variance-authority for class handling.

Two dependencies are worth calling out because they are not obvious. satori and satori-html render images as SVG from markup, which is how a site like this produces share images for 300 entries without hand drawing them. And sharp handles image processing for the same reason. schema-dts provides TypeScript types for JSON Schema, which is what OpenAPI documents are.

posthog-js is the analytics, and the .env.example at the root of the repository is explicit about it:

PUBLIC_POSTHOG_API_KEY=phc_...

with a comment saying it is for product analytics and is not needed for local development or CI. A public key is a public key, so this is not a secret, but it is the only environment variable the project defines.

Local development is pnpm on Node 24, plus a link checker

The development section is two commands. Run this first:

corepack enable
pnpm install

corepack enable is what makes the pinned package manager available, and the README says pnpm uses the package manager version pinned in package.json. The manifest pins [email protected] and requires node ^24.16.0 with pnpm ^11.1.2, and the README says to use Node.js 24 with this project. The pnpm-lock.yaml and pnpm-workspace.yaml files at the root are what make that pin meaningful.

The scripts tell you what the project actually checks. The build runs astro check and astro build, so type checking is part of building rather than a separate step:

    "build": "astro check && astro build",
    "check-links": "node scripts/check-tool-links.mjs",
    "depcheck": "knip",
    "test": "vitest run"

The check-links script is the one that matters most for a directory, because a listing of 300 external tools rots when those tools change their URLs or disappear. depcheck runs knip to find unused dependencies, and the test script runs vitest.

Linting and formatting are handled by oxlint and oxfmt with their own config files, .oxlintrc.json and .oxfmtrc.json, rather than the more common eslint and prettier pairing. The Netlify deploy status badge at the top of the README reflects the hosting side, and netlify.toml and astro.config.mjs are the configuration for it.

MIT, no release tags, and a repository that is mostly content

The licence is MIT, stated in the README and with the LICENSE file at the root of the repository. The site itself is also MIT, and the tooling in it is a separate set of licences that belong to each dependency. None of that is unusual, and none of it is a reason for caution in itself.

There are no GitHub releases for this project, which is consistent with what it is. A static site deployed by Netlify from the main branch has no need for a versioned release, and the Netlify badge is the signal that matters. The last push was on 2026-10-18 and the repository is not archived.

The file list shows a content repository rather than a library. src/ and public/ hold the site, scripts/ holds the link checker and whatever else the build needs, img/ holds images, and the root holds the Astro configuration, the TypeScript configuration, vitest.config.ts, knip.config.ts, components.json for the component library, CNAME for the custom domain, and a .ruby-version file that suggests a small script or tool in the repository is Ruby.

The result is a project with a very different upgrade profile from a library. Cloning it and running the two commands gives you the site, and there is nothing to upgrade in the usual sense.

Where openapi.tools is the wrong tool

The first wrong fit is a team that wants an independent evaluation. The directory is a discovery index with filters, and the only automated verification the repository describes is a link check on the tool URLs. Nothing in the README describes tests that exercise the listed tools, check their output against the specification, or compare them on a common task. A listing that a tool disappears from is not a listing that tells you which tool is better.

The second is a tool for generating or validating an API. This site does not read your OpenAPI document, it points at programs that do. If your problem is producing a client from a specification, you need one of the listed generators, and this directory is only the step before that.

The third is a compliance question. The directory indexes tools across many languages and both the 3.0 and 3.1 generations, and it deliberately keeps pre-3.1 tools in a legacy collection rather than excluding them. That is the right call for a browsing tool and the wrong one if you need an approved list for a regulated environment, where a curated internal catalogue with a named owner is the artefact you actually want.

The fourth is offline use. The site is a hosted application with search, filters and a command palette, and the underlying data is not documented as a file you can vendor into a repository. If your team wants the list in version control, you are transcribing it by hand.

Editorial conclusion

openapi.tools fits an engineer who knows the shape of the problem but not the name of the tool, and who needs to separate options by OpenAPI version and language in one place. It does not fit a team that wants an independent ranking, because sponsored tools get priority placement and a badge, and the only automated check the repository runs is a link check. Before relying on it, filter to your OpenAPI version and treat the ordering as a sponsored index rather than an evaluation.

Frequently asked questions

Official sources

1. apisyouwonthate/openapi.tools on GitHub
2. Issues
3. License: MIT
4. Project website
5. README