openai-openapi publishes two generated spec files and no source you can patch

Both files here are generated, and the source sits in another repository

There is no source code in this repository to contribute to. `openapi.yaml` and `openapi.json` are generated artifacts synchronized automatically from an upstream source, and an edit made here does not update that source. The authoring guide is reached through a path inside a different repository, under `lib/js/oai_js_apidocs_data/src/openapi/README.md` in openai/openai, which is a JavaScript tree holding the origin of a language neutral document. Maintainers make corrections there and the publication workflow writes the YAML and the JSON here afterwards. That arrangement explains the rest of the layout: there is no test suite, no build script, and no schema lint configuration in the tree, and the repository records no primary language at all, because what it publishes is a description rather than an implementation.

The release tags stopped in 2023 while the branch kept moving

The version history here is two entries: 2.0.0 published on 2023-06-19 and 1.3.0 published on 2023-06-13, six days earlier. The default branch, by contrast, was last pushed on 2026-10-03, and the repository is not archived. Nothing in the tree reconciles those two facts, and there is no changelog file to tell you what a tag contains. The documented download makes the same point in practice, since it fetches from the branch rather than from a release.

curl -L https://raw.githubusercontent.com/openai/openai-openapi/main/openapi.yaml \
  -o openai-openapi.yaml

So a consumer following the instructions gets whatever is on main at that moment, with no version identifier attached to it. If your build needs a stable definition, the commit you fetched becomes your version marker, and nothing in this repository will tell you later which one you had.

Pull requests are limited to OpenAI team members, so issues are the only channel

The contribution policy is the first structural fact a reader meets. Everyone is welcome to file issues and suggestions, but pull requests are limited to OpenAI team members, and that restriction covers documentation and asset suggestions too, not just schema changes. Team members may submit pull requests for repository policy, documentation, and assets, subject to required review, and the full policy lives in CONTRIBUTING.md. What an outside reporter is asked for is specific: the affected revision, the endpoint with its HTTP method or the schema name, the expected behaviour, and a minimal example built from synthetic data, with credentials, customer data, and private URLs removed from both examples and diagnostic output. Triage is described as a best effort attempt, which sets the expectation for how long a schema correction may take. Nothing in the policy says how quickly an accepted issue reaches the generated files, or whether a landed correction is announced anywhere a consumer would see.

Two copies of one document, and the download hands you only the YAML

The same specification is published twice, as `openapi.yaml` and `openapi.json`, both generated from the same upstream source. The quick way to get it points at the YAML and writes it to a local file, leaving the JSON copy for anyone whose tooling prefers it. Because the artifacts are produced by an automated workflow rather than edited, a mismatch between the two would be a workflow problem, not a merge conflict, and the repository holds no step you could run to compare them. Neither copy carries a self description of the upstream revision it came from, so the only way to tell two snapshots apart is to diff them. Consumers also inherit the format requirement: the document is authored in OpenAPI 3.1, and the README's framing is that it can be imported into tools that support the OpenAPI ecosystem. A validator or generator that only understands the earlier 3.0 dialect is outside what this document was written for.

Prose questions are redirected, and the recorded homepage points at a different site

This repository is deliberately not a documentation site. A note near the top sends anyone looking for human readable documentation, guides, and examples to the OpenAI API docs on developers.openai.com, and the two links in the header go to that same documentation domain for the API reference, next to a local link labelled Explore the spec that points at the YAML file itself and a link to support. The homepage recorded for the repository is a third address, platform.openai.com/docs/api-reference/introduction, which is neither of those. That split is worth knowing before you file anything: schema accuracy belongs in the issues here, while how to use the API belongs on the documentation site. Two root entries also go unexplained, with `AGENTS.md` and an `assets/` directory present in the tree and no mention of either in the README.

Six SDKs trace their shape back to one regenerated file

The repository names six official SDKs as generated from this specification, mapping Python to openai-python, JavaScript and TypeScript to openai-node, .NET to openai-dotnet, Go to openai-go, Java to openai-java, and Ruby to openai-ruby. That makes this file the common ancestor for every one of those client libraries, which is the practical reason to care about its exact contents: a schema correction here propagates into six languages at once, and a wrong field name propagates with it. The About section frames the intended uses as generating typed clients, building API explorers, configuring testing tools, or working in any OpenAPI-compatible workflow, which is four different consumers of one file. The flip side is that the propagation is invisible from here. The workflow rewrites the artifacts and this repository shows no diff, no review trail, and no note about which SDK release picked up which revision of the file. Anyone debugging a mismatch between a generated client and the live API is left to compare the file on main against the client version they hold.

Vulnerabilities go to a private file, and the license is the short one

Security reports have their own route and it is deliberately narrow: suspected vulnerabilities are to be reported privately using SECURITY.md, not in public issues or pull requests. Everything else, including a wrong schema or a missing field, goes to the issue tracker, where the guidance is to search first and open a new issue only if it has not been reported. For API problems rather than spec problems, the README points at OpenAI Support instead. Licensing is the MIT License at the root, and unlike the specification itself the policy documents are maintained in the open: CONTRIBUTING.md for the contribution rules, SECURITY.md for private reporting, and the README for the rest. No code of conduct file appears in the tree.

Editorial conclusion

Use this repository as a reference document, not as a dependency you can pin. The two files on the default branch are regenerated from an upstream source, direct edits do not travel back, and the release tags stopped in 2023 while the branch keeps moving, so pin a commit and record it yourself. Send schema problems through issues with a synthetic example, send anything that looks like a vulnerability to the private channel described in SECURITY.md, and go to the documentation site for anything phrased as a how to.

Frequently asked questions

Official sources

1. License: MIT
2. openai/openai-openapi on GitHub
3. Project website
4. README
5. Releases