Orval vs Kubb for the Sume OpenAPI spec: which generator fits

The answer

Choose Orval when you want one configured client style, such as react-query with split files, from the Sume spec. Choose Kubb when you want to mix outputs, for example types plus Zod validators plus SWR hooks plus MSW mocks, from one parsed document. Both read Sume's OpenAPI JSON; neither changes how you must handle async jobs.

Everything below comes from each tool's own home page. Neither page makes a claim about Sume, so the mapping to Sume is ours.

What each page says

Orval's page shows a config object with output.mode, output.client and input.target, and describes generating one custom hook per path. Kubb's page describes an adapter that parses a spec into a shared AST and a list of plugins, run with npx kubb generate.

How that plays with Sume

Sume's document is OpenAPI 3.0.3 with 183 operations and nullable fields. For a React app that only needs typed hooks, Orval's single client option is the shortest path. For a service that wants validated payloads at the edge, Kubb's Zod plugin is the closer fit.

In both cases the job flow is yours to write. A create returns a job; you poll status_url until terminal is true, wait at least next_poll_after_seconds between reads, and fetch result_url when result_ready is true. Generated code gives you the calls and types, not that loop.

Questions to settle first

Decide whether you need runtime validation, whether you want mocks for tests, and whether you target one framework or several. If you need none of the extras, a types-only generator may be enough; see the client guide for the options.

Whatever you pick, commit the spec copy you generated from and send Idempotency-Key on every create, since generators do not add it for you.

A rule of thumb

Small team, one front end, one data library: Orval. Several consumers, validation at the edge, mocks in tests: Kubb. Either way, keep the generated tree out of hand edits, regenerate from a committed copy of the spec, and put the job loop and the idempotency key in a thin wrapper that you own and test.

If you are unsure, generate with both for one tag, such as Jobs, and compare the files. The cost of trying is one config file each, and the difference in output is easier to judge on real code than from a feature table.