Turn an OpenAPI Spec Into a CLI People Can Actually Use

Most teams already have more API structure than they use.

If you have a FastAPI app, a Swagger spec, or any OpenAPI 3.x document, the spec already knows your paths, methods, query parameters, path parameters, request bodies, auth schemes, enums, and validation rules.

And yet, a lot of internal API workflows still end up as copied curl commands:

curl -X POST "$API_URL/users" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"Jane","email":"jane@example.com","address":{"city":"NYC","state":"NY"}}'

That works, but it is not a great interface. It is easy to mistype. It is hard to discover. It asks humans to write JSON even when the schema already knows the fields.

I built openapi-cli-gen to explore a narrower idea: what if an OpenAPI spec could become a human-facing command line app?

The Basic Idea

Instead of making users paste JSON, generate commands like this:

mycli users create \
  --name Jane \
  --address.city NYC \
  --address.state NY

The OpenAPI spec provides the structure. The generated CLI exposes that structure as command groups, options, environment variables, and output formats.

Why Not Just Use OpenAPI Generator?

OpenAPI Generator is excellent when you need SDKs, server stubs, models, or language-specific client libraries. That is not the same job.

The distinction is:

SDK generator: produce code developers import.
CLI generator: produce commands humans and scripts run.

Proof: Generated CLIs From Real APIs

This is not only a design sketch. The generator has already been used to create standalone CLI wrappers for real APIs:

OpenAI REST CLI: chat, embeddings, files, vector stores, batch, fine-tuning, images, audio, and more.
Qdrant REST CLI: collections, points, search, snapshots, and vector database operations.
Meilisearch REST CLI: indexes, documents, search, settings, tasks, and API keys.
Typesense REST CLI: collections, documents, search, aliases, keys, analytics, and conversations.
AdGuard Home CLI: filtering, clients, DHCP, rewrite rules, TLS, stats, and admin operations.
Immich REST CLI: assets, albums, libraries, users, search, tags, server config, and upload workflows.

That matters because the value is not just "can we generate code?" The value is whether the generated surface can become a useful package someone can install, inspect, and script.

FastAPI Is A Natural Fit

FastAPI publishes an OpenAPI spec at /openapi.json by default. That means a running FastAPI app can become a CLI without adding a separate API description file:

openapi-cli-gen generate \
  --spec http://localhost:8000/openapi.json \
  --name internal-admin

Nested Request Bodies Are The Pain Point

The easy part of an API CLI is path and query parameters. The annoying part is request bodies.

internal-admin users create \
  --name Jane \
  --email jane@example.com \
  --address.city NYC \
  --address.state NY

For complex cases, JSON fallback is still available:

internal-admin users create \
  --address '{"city":"NYC","state":"NY"}'

Try It

pipx install openapi-cli-gen

openapi-cli-gen inspect \
  --spec https://petstore3.swagger.io/api/v3/openapi.json

Project: https://github.com/shivaam/openapi-cli-gen

I am especially interested in real OpenAPI specs that make generated CLIs awkward: unusual auth, nested bodies, arrays of objects, multipart uploads, unions, or very large schemas.