Options for OpenAPI Generator are the same whether you're using the CLI, Maven/Gradle Plugins, or Online generation options.This page demonstrates navigating the options via CLI. Commands are presented here in a logical progression as a tutorial, but you're welcome to skip directly to the generate command.

help

The help option lists all commands available to the CLI.

  1. openapi-generator help
  2. usage: openapi-generator-cli <command> [<args>]
  3. The most commonly used openapi-generator-cli commands are:
  4. config-help Config help for chosen lang
  5. generate Generate code with the specified generator.
  6. help Display help information
  7. list Lists the available generators
  8. meta MetaGenerator. Generator for creating a new template set and configuration for Codegen. The output will be based on the language you specify, and includes default templates to include.
  9. validate Validate specification
  10. version Show version information
  11. See 'openapi-generator-cli help <command>' for more information on a specific
  12. command.

list

The list command outputs a formatted list of every available generator. Pass the -s/—short option if you would like a CSV output for easy parsing.

  1. openapi-generator help list
  2. NAME
  3. openapi-generator-cli list - Lists the available generators
  4. SYNOPSIS
  5. openapi-generator-cli list [(-i <include> | --include <include>)]
  6. [(-s | --short)]
  7. OPTIONS
  8. -i <include>, --include <include>
  9. comma-separated list of stability indexes to include (value:
  10. all,beta,stable,experimental,deprecated). Excludes deprecated by
  11. default.
  12. -s, --short
  13. shortened output (suitable for scripting)

Example:

  1. openapi-generator list -s | tr ',' '\n'

For the full list of generators, refer to the Generators List.

config-help

The config-help option provides details about

  1. openapi-generator help config-help
  2. NAME
  3. openapi-generator-cli config-help - Config help for chosen lang
  4. SYNOPSIS
  5. openapi-generator-cli config-help
  6. [(-f <output format> | --format <output format>)]
  7. [(-g <generator name> | --generator-name <generator name>)]
  8. [--markdown-header] [--named-header]
  9. [(-o <output location> | --output <output location>)]
  10. OPTIONS
  11. -f <output format>, --format <output format>
  12. Write output files in the desired format. Options are 'text',
  13. 'markdown' or 'yamlsample'. Default is 'text'.
  14. -g <generator name>, --generator-name <generator name>
  15. generator to get config help for
  16. --markdown-header
  17. When format=markdown, include this option to write out markdown
  18. headers (e.g. for docusaurus).
  19. --named-header
  20. Header includes the generator name, for clarity in output
  21. -o <output location>, --output <output location>
  22. Optionally write help to this location, otherwise default is
  23. standard output

The option of note is -g/—generator-name (other options are exposed for tooling).

You may pass any generator name (see list command) to -g, and options specific to that generator will be displayed. Some generators have many options, while others may have only a few.

Example:

  1. openapi-generator config-help -g go

Outputs:

  1. CONFIG OPTIONS
  2. packageName
  3. Go package name (convention: lowercase). (Default: openapi)
  4. hideGenerationTimestamp
  5. Hides the generation timestamp when files are generated. (Default: true)
  6. packageVersion
  7. Go package version. (Default: 1.0.0)
  8. withGoCodegenComment
  9. whether to include Go codegen comment to disable Go Lint and collapse by default GitHub in PRs and diffs (Default: false)
  10. withXml
  11. whether to include support for application/xml content type and include XML annotations in the model (works with libraries that provide support for JSON and XML) (Default: false)
  12. prependFormOrBodyParameters
  13. Add form or body parameters to the beginning of the parameter list. (Default: false)

To pass these go client generator-specific options to the generate command for a go client, use the —additional-properties option. See the generate command section for an example.

meta

The meta command creates a new Java class and template files, used for creating your own custom templates.

  1. openapi-generator help meta
  2. NAME
  3. openapi-generator-cli meta - MetaGenerator. Generator for creating a new
  4. template set and configuration for Codegen. The output will be based on
  5. the language you specify, and includes default templates to include.
  6. SYNOPSIS
  7. openapi-generator-cli meta [(-n <name> | --name <name>)]
  8. [(-o <output directory> | --output <output directory>)]
  9. [(-p <package> | --package <package>)] [(-t <type> | --type <type>)]
  10. OPTIONS
  11. -n <name>, --name <name>
  12. the human-readable name of the generator
  13. -o <output directory>, --output <output directory>
  14. where to write the generated files (current dir by default)
  15. -p <package>, --package <package>
  16. the package to put the main class into (defaults to
  17. org.openapitools.codegen)
  18. -t <type>, --type <type>
  19. the type of generator that is created

For an in-depth example of using the meta command, see Customization.

validate

The validate command allows you to validate an input specification, optionally providing recommendations for error fixes or other improvements (if available).

  1. openapi-generator help validate
  2. NAME
  3. openapi-generator-cli validate - Validate specification
  4. SYNOPSIS
  5. openapi-generator-cli validate
  6. (-i <spec file> | --input-spec <spec file>) [--recommend]
  7. OPTIONS
  8. -i <spec file>, --input-spec <spec file>
  9. location of the OpenAPI spec, as URL or file (required)
  10. --recommend

Valid Spec Example (using petstore-v3.0.yaml)

  1. openapi-generator validate -i petstore-v3.0.yaml
  1. Validating spec (petstore-v3.0.yaml)
  2. No validation issues detected.

Invalid Spec Example (using petstore-v3.0-invalid.yaml):

  1. openapi-generator validate -i petstore-v3.0-invalid.yaml
  1. Validating spec (petstore-v3.0-invalid.yaml)
  2. Errors:
  3. -attribute info is missing
  4. [error] Spec has 1 errors.

completion

Although not documented in the help output, the CLI offers a completion command, which can be used for auto-completion.

This command takes one or more parameters representing the args list you would otherwise pass to openapi-generator. For example:

  1. openapi-generator completion config-help
  2. -o
  3. --output
  4. --named-header
  5. -g
  6. --generator-name
  7. -f
  8. --format
  9. --markdown-header

An example bash completion script can be found in the repo at scripts/openapi-generator-cli-completion.bash.

generate

The generate command is the workhorse of the generator toolset. As such, it has many more options and the previous commands. The options are abbreviated below, but you may expand the full descriptions.

  1. openapi-generator help generate
  2. NAME
  3. openapi-generator-cli generate - Generate code with the specified
  4. generator.
  5. SYNOPSIS
  6. openapi-generator-cli generate
  7. [(-a <authorization> | --auth <authorization>)]
  8. [--api-package <api package>] [--artifact-id <artifact id>]
  9. [--artifact-version <artifact version>]
  10. [(-c <configuration file> | --config <configuration file>)]
  11. [-D <system properties>...]
  12. [(-e <templating engine> | --engine <templating engine>)]
  13. [--enable-post-process-file]
  14. [(-g <generator name> | --generator-name <generator name>)]
  15. [--generate-alias-as-model] [--git-repo-id <git repo id>]
  16. [--git-user-id <git user id>] [--group-id <group id>]
  17. [--http-user-agent <http user agent>]
  18. (-i <spec file> | --input-spec <spec file>)
  19. [--ignore-file-override <ignore file override location>]
  20. [--import-mappings <import mappings>...]
  21. [--instantiation-types <instantiation types>...]
  22. [--invoker-package <invoker package>]
  23. [--language-specific-primitives <language specific primitives>...]
  24. [--library <library>] [--log-to-stderr] [--minimal-update]
  25. [--model-name-prefix <model name prefix>]
  26. [--model-name-suffix <model name suffix>]
  27. [--model-package <model package>]
  28. [(-o <output directory> | --output <output directory>)]
  29. [(-p <additional properties> | --additional-properties <additional properties>)...]
  30. [--package-name <package name>] [--release-note <release note>]
  31. [--remove-operation-id-prefix]
  32. [--reserved-words-mappings <reserved word mappings>...]
  33. [(-s | --skip-overwrite)] [--server-variables <server variables>...]
  34. [--skip-validate-spec] [--strict-spec <true/false strict behavior>]
  35. [(-t <template directory> | --template-dir <template directory>)]
  36. [--type-mappings <type mappings>...] [(-v | --verbose)]
generate OPTIONS
  1. OPTIONS -a <authorization>, auth <authorization> adds authorization headers when fetching the OpenAPI definitions remotely. Pass in a URL-encoded string of name:header with a comma separating multiple values api-package <api package> package for generated api classes artifact-id <artifact id> artifactId in generated pom.xml. This also becomes part of the generated library's filename —artifact-version <artifact version> artifact version in generated pom.xml. This also becomes part of the generated library's filename -c <configuration file>, config <configuration file> Path to configuration file configuration file. It can be json or yaml.If file is json, the content should have the format {"optionKey":"optionValue", "optionKey1":"optionValue1"…}.If file is yaml, the content should have the format optionKey: optionValueSupported options can be different for each language. Run config-help -g {generator name} command for language specific config options. -D <system properties> sets specified system properties in the format of name=value,name=value (or multiple options, each with name=value) -e <templating engine>, engine <templating engine> templating engine: "mustache" (default) or "handlebars" (beta) enable-post-process-file enablePostProcessFile -g <generator name>, generator-name <generator name> generator to use (see list command for list) generate-alias-as-model Generate alias to map, array as models git-repo-id <git repo id> Git repo ID, e.g. openapi-generator. git-user-id <git user id> Git user ID, e.g. openapitools. group-id <group id> groupId in generated pom.xml http-user-agent <http user agent> HTTP user agent, e.g. codegencsharp_api_client, default to 'OpenAPI-Generator/{packageVersion}}/{language}' -i <spec file>, input-spec <spec file> location of the OpenAPI spec, as URL or file (required) ignore-file-override <ignore file override location> Specifies an override location for the .openapi-generator-ignore file. Most useful on initial generation. import-mappings <import mappings> specifies mappings between a given class and the import that should be used for that class in the format of type=import,type=import. You can also have multiple occurrences of this option. instantiation-types <instantiation types> sets instantiation type mappings in the format of type=instantiatedType,type=instantiatedType.For example (in Java): array=ArrayList,map=HashMap. In other words array types will get instantiated as ArrayList in generated code. You can also have multiple occurrences of this option. invoker-package <invoker package> root package for generated code language-specific-primitives <language specific primitives> specifies additional language specific primitive types in the format of type1,type2,type3,type3. For example: String,boolean,Boolean,Double. You can also have multiple occurrences of this option. library <library> library template (sub-template) log-to-stderr write all log messages (not just errors) to STDOUT. Useful for piping the JSON output of debug options (e.g. -DdebugOperations) to an external parser directly while testing a generator. minimal-update Only write output files that have changed. model-name-prefix <model name prefix> Prefix that will be prepended to all model names. Default is the empty string. model-name-suffix <model name suffix> Suffix that will be appended to all model names. Default is the empty string. model-package <model package> package for generated models -o <output directory>, output <output directory> where to write the generated files (current dir by default) -p <additional properties>, additional-properties <additional properties> sets additional properties that can be referenced by the mustache templates in the format of name=value,name=value. You can also have multiple occurrences of this option. package-name <package name> package for generated classes (where supported) release-note <release note> Release note, default to 'Minor update'. remove-operation-id-prefix Remove prefix of operationId, e.g. config_getId => getId reserved-words-mappings <reserved word mappings> specifies how a reserved name should be escaped to. Otherwise, the default <name> is used. For example id=identifier. You can also have multiple occurrences of this option. -s, skip-overwrite specifies if the existing files should be overwritten during the generation. server-variables <server variables> sets server variables for spec documents which support variable templating of servers. skip-validate-spec Skips the default behavior of validating an input specification. strict-spec <true/false strict behavior> 'MUST' and 'SHALL' wording in OpenAPI spec is strictly adhered to. e.g. when false, no fixes will be applied to documents which pass validation but don't follow the spec. -t <template directory>, —template-dir <template directory> folder containing the template files —type-mappings <type mappings> sets mappings between OpenAPI spec types and generated code types in the format of OpenAPIType=generatedType,OpenAPIType=generatedType. For example: array=List,map=Map,string=String. You can also have multiple occurrences of this option. -v, —verbose verbose mode

At a minimum, generate requires:

  • -g to specify the generator
  • -o to specify a meaningful output directory (defaults to the current directory!)
  • -i to specify the input OpenAPI document

Examples

The following examples use petstore.yaml.

Additional Properties

Generator-specific options should be passed as —additional-properties:

  1. openapi-generator generate -g go --additional-properties=prependFormOrBodyParameters=true \
  2. -o out -i petstore.yaml

To pass more than one generator property, these can be combined via comma:

  1. --additional-properties=key1=value1,key2=value2

For the full list of generator-specified parameters, refer to generators docs.

Type Mappings and Import Mappings

Most generators allow for types bound to the OpenAPI Specification's types to be remapped to a user's desired types. Not all type mappings can be reassigned, as some generators define mappings which are tightly coupled to the built-in templates.

If you're not using your own templates with star/glob package imports, you will most likely need to combine —type-mappings and —import-mappings together.

  • —type-mappings Defines the user's target type
  • —import-mappings Informs the template of the type to be importedHere's how one might change the kotlin-spring server generator's default of OffsetDateTime to LocalDateTime:
  1. openapi-generator generate \
  2. -i petstore.yaml \
  3. -g kotlin-spring \
  4. -o out \
  5. --additional-properties=library=spring-boot,beanValidations=true,swaggerAnnotations=true,serviceImplementation=true \
  6. --import-mappings=DateTime=java.time.LocalDateTime \
  7. --type-mappings=DateTime=java.time.LocalDateTime

NOTE: mappings are applied to DateTime, as this is the representation of the primitive type. See DefaultCodegen.

Target External Models

Sometimes you don't want the codegen to make a model for you—you might want to just include one that already exists in your codebase. Say you already have a User object and want to reuse that, which has a different model package from the other generated files:

First, indicate that the class is already included by default. This will keep the codegen from trying to generate the class.

  1. --language-specific-primitives=Pet

This command line option will tell the generator to consider Pet a "primitive" type.

Next, if the Pet class is a different package, add an —import-mapping to tell the generator to include that import wherever Pet is used:

  1. --import-mappings=Pet=com.yourpackage.models.Pet

Now the codegen will know what to import from that specific package.

NOTE: import-mappings is assigned a key-value pair in this example, but multiple values can be comma-separate. For instance:

  1. --import-mappings=Pet=com.yourpackage.models.Pet,User=com.yourpackage.models.User

Configuration File

Rather than passing generator options in a CSV of —additional-properties, you may also provide the settings via JSON file or YAML file.

For example, one of our typescript samples has the following configuration file:

  1. {
  2. "npmName": "@swagger/typescript-fetch-petstore",
  3. "npmVersion": "1.0.0",
  4. "npmRepository" : "https://skimdb.npmjs.com/registry",
  5. "snapshot" : false,
  6. "supportsES6": true
  7. }

These settings can be passed via -c filename. Here, we've saved the above as config.json:

  1. openapi-generator generate -i petstore.yaml -g typescript-fetch -o out \
  2. -c config.json

Same configuration file can be passed into YAML format having following equivalent content:

  1. npmName: "@swagger/typescript-fetch-petstore"
  2. npmVersion: "1.0.0"
  3. npmRepository: "https://skimdb.npmjs.com/registry"
  4. snapshot: false
  5. supportsES6: true

The settings are passed exactly the same as for config.json. The most important part is the file extension. Supported values are yml or yaml.The name of the file should be config.yml or config.yaml (in our example it will be config.yaml.

  1. openapi-generator generate -i petstore.yaml -g typescript-fetch -o out \
  2. -c config.yaml