Yes. Global properties let you generate a chosen set of APIs or models, and switch off tests and docs. A smaller client means less code to review, fewer exposed operations and less to patch. It does not remove the libraries the generator adds to the project.
What the docs describe
The customization page explains selective generation through global properties. You can name specific models, for example a list separated by colons, or name specific APIs. You can also turn off model tests or API tests with their own properties. When you use selective generation, the docs say the templates needed for that run are the ones used.
A related option skips models generated from form parameters, which differ in OpenAPI 3 because it has no form parameter in the same way.
openapi-generator generate -i spec.yaml -g java -o out \
--global-property apis=Orders,models=Order:Item,modelTests=false
Check the exact syntax for your generator in its docs before relying on it.
Why a smaller client is safer
| Benefit | Explanation |
|---|---|
| Less code to review | Reviewers read what you call, not the whole vendor API |
| Fewer callable operations | A dangerous endpoint you never use is not in your client at all |
| Smaller diffs on regeneration | Fewer files change when the spec grows |
| Fewer files to scan and triage | Findings in unused generated code stop appearing |
The second point is easy to overlook. If your service reads orders but never changes them, a client that also contains delete and admin operations makes it easier for a future change, or a compromised dependency, to call them.
What it does not fix
- The project still declares an HTTP library, a JSON library and annotations, as covered in the swagger annotations post.
- Shared models that selected operations depend on are still generated, so the set may be bigger than your list.
- The generated client configuration, such as TLS and timeouts, is unchanged.
How to adopt it
- List the operations your code actually calls. A search for the generated API class names in your repo gives you this.
- Put the selection in your config file under version control, so the choice is reviewable.
- Regenerate and compare the file list with the previous output.
- Add a CI step that fails if code starts calling an operation that is not in the selection.
- Revisit the list when you add features, instead of switching back to everything.
Selective generation fits well with committing the generated output, as discussed in commit generated code or generate at build time.
Where Safeguard fits
Safeguard's reachability analysis works on the same principle at the dependency level: findings in code your application cannot reach are separated from those it can. SBOM and dependency scanning cover what remains.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how filtering to reachable findings changes the list you have to work through.
Quick check
Does selective generation remove unused dependencies?
No. It trims generated source files, not the libraries the generated project declares.
Where should the selection live?
In a config file in version control, so changes get reviewed.
Sources
Last reviewed: 19 October 2026.
