● Beta — KubeEra is in active development. Profiles are live; AI-perception measurement is rolling out.
KubeEra
O

OpenAPI

App Definition & Delivery
Open source · Apache-2.0

OpenAPI is a specification, not a product. It defines a language-agnostic, machine-readable format (JSON or YAML) for describing REST API surfaces: endpoints, request/response schemas, auth schemes, parameters, and status codes.

updated 2026-07-01

What it is

OpenAPI is a specification, not a product. It defines a language-agnostic, machine-readable format (JSON or YAML) for describing REST API surfaces: endpoints, request/response schemas, auth schemes, parameters, and status codes. The repo (OAI/OpenAPI-Specification) is where the spec text itself lives — it's Markdown because you're reading a standards document, not shipping a binary. The actual tooling ecosystem (code generators, validators, mock servers, documentation renderers like Swagger UI, Redoc, Stoplight) is built by third parties around this spec, not in this repo.

If you've written a openapi.yaml or swagger.json file, you were following this spec.

Who builds it and why

Maintained under the Linux Foundation via the OpenAPI Initiative (OAI), with governance from a Technical Steering Committee. Contributors come from companies with a direct stake in API tooling and standards: cloud vendors, API gateway vendors, and platform teams who need a stable contract format so their tooling doesn't fragment. 253 contributors over the project's life is consistent with a standards body — wide input, but a smaller core group actually drives spec versions forward. The incentive is straightforward: nobody wants five incompatible ways to describe a REST API, so vendors collaborate here even while competing on tooling built on top of it.

Production readiness signal

This isn't software you deploy, so "production readiness" means spec stability and ecosystem adoption, not uptime or crash rates.

  • 31,065 GitHub stars and active commits into 2026 indicate a spec still under real iteration, not abandoned.
  • Version 3.2.0 as the latest release shows continued evolution past the long-dominant 3.0.x/3.1.x lines — check the changelog before adopting if you're pinned to an older major version; tooling support for the newest minor releases often lags the spec itself by months.
  • CNCF maturity level: not publicly available in the data given — OpenAPI is not a CNCF project (it sits under the Linux Foundation via OAI, a separate structure), so don't conflate it with CNCF's sandbox/incubating/graduated ladder.
  • License is Apache-2.0, which is irrelevant to runtime risk but relevant if you're vendoring the spec docs or generator templates.

The real production signal you should evaluate is downstream: does your generator (openapi-generator, Swagger Codegen, Stoplight, Redocly) support the spec version you're targeting? That gap is usually the actual blocker, not the spec itself.

Who should use this

  • Teams building or consuming REST APIs who want machine-readable contracts for codegen, testing, and documentation.
  • Platform teams standardizing API design across many services/teams — OpenAPI gives you a lingua franca for API review, mock servers, and contract testing.
  • Anyone integrating with API gateways, service meshes, or API management platforms — most of them ingest OpenAPI natively.

Who should NOT use this

  • Teams building gRPC or event-driven (async/Kafka-style) APIs — OpenAPI describes synchronous HTTP/REST; use Protobuf/gRPC reflection or AsyncAPI instead.
  • Small teams with 2-3 internal endpoints and no external consumers — the overhead of maintaining a spec file in lockstep with code may not pay off versus just documenting inline.
  • Anyone expecting this repo to be a tool — it's a spec document. You still need to pick and integrate third-party tooling, which varies wildly in quality and OpenAPI-version support.
  • Teams needing strict backward-compatibility guarantees on GraphQL-style flexible queries — wrong paradigm entirely.

Alternatives

  • AsyncAPI — same idea, but for event-driven/async APIs (message queues, websockets, pub/sub).
  • gRPC/Protobuf — schema-first RPC framework with strong typing and codegen, better fit for internal service-to-service calls than REST-style contracts.
  • GraphQL SDL — schema language for GraphQL APIs; different query model, not a drop-in replacement but often the alternative teams actually compare against for public APIs.

Pricing

Fully open source, Apache-2.0, free to use with no strings attached. The spec itself costs nothing; any cost comes from the third-party tooling you choose to build documentation, SDKs, or gateways on top of it — and pricing there varies by vendor.

Frequently asked

What is OpenAPI?+
OpenAPI is a specification, not a product. It defines a language-agnostic, machine-readable format (JSON or YAML) for describing REST API surfaces: endpoints, request/response schemas, auth schemes, parameters, and status codes.
Who builds OpenAPI?+
Maintained under the Linux Foundation via the OpenAPI Initiative (OAI), with governance from a Technical Steering Committee.
Is OpenAPI production ready?+
This isn't software you deploy, so "production readiness" means spec stability and ecosystem adoption, not uptime or crash rates. 31,065 GitHub stars and active commits into 2026 indicate a spec still under real iteration, not abandoned. Version 3.2.
Who should use OpenAPI?+
Teams building or consuming REST APIs who want machine-readable contracts for codegen, testing, and documentation. Platform teams standardizing API design across many services/teams — OpenAPI gives you a lingua franca for API review, mock servers, and contract testing.
Who should not use OpenAPI?+
Teams building gRPC or event-driven (async/Kafka-style) APIs — OpenAPI describes synchronous HTTP/REST; use Protobuf/gRPC reflection or AsyncAPI instead.
What are the alternatives to OpenAPI?+
AsyncAPI — same idea, but for event-driven/async APIs (message queues, websockets, pub/sub). gRPC/Protobuf — schema-first RPC framework with strong typing and codegen, better fit for internal service-to-service calls than REST-style contracts.
How much does OpenAPI cost?+
Fully open source, Apache-2.0, free to use with no strings attached. The spec itself costs nothing; any cost comes from the third-party tooling you choose to build documentation, SDKs, or gateways on top of it — and pricing there varies by vendor.