# generators.yml configuration schema > Complete generators.yml configuration reference for Fern SDK generation. Configure authentication, publishing, GitHub integration, and language-specific settings. The `generators.yml` file serves two purposes: it declares your API definition (required for OpenAPI/AsyncAPI), and configures SDK generation, including which languages to generate, where to publish them, and how to customize each SDK. ```yaml title="generators.yml" maxLines=10 api: specs: - openapi: "./openapi.yml" namespace: "v1" settings: title-as-schema-name: true inline-path-parameters: false respect-forward-compatible-enums: true whitelabel: github: username: "my-org" email: "sdk@mycompany.com" token: "ghp_xxxxxxxxxxxx" metadata: description: "Official SDK for MyAPI" authors: - name: "SDK Team" email: "sdk@mycompany.com" readme: introduction: "Welcome to the MyAPI SDK" apiReferenceLink: "https://docs.myapi.com" defaultEndpoint: method: "GET" path: "/users" features: authentication: - "POST /auth/login" - "GET /auth/profile" users: - "GET /users" - "POST /users" default-group: "production" groups: production: generators: - name: fernapi/fern-typescript-sdk version: 0.9.0 - name: fernapi/fern-python-sdk version: 2.0.0 ``` ## `auth-schemes` Define authentication methods for your API that your endpoints can reference. Authentication schemes defined in `generators.yml` take precedence over authentication schemes defined in your spec. Choose from custom headers (API keys), HTTP Basic, Bearer token, or OAuth 2.0 authentication. Alternatively, you can [define authentication for individual SDKs](#override-api-authentication-settings). ```yaml title="generators.yml" maxLines=10 auth-schemes: # User-defined scheme name - OAuth with minimal configuration simple-oauth: scheme: oauth type: client-credentials get-token: endpoint: "auth.token" # User-defined scheme name - Header auth with custom configuration custom-header: name: "Custom Auth" header: "X-Custom-Auth" prefix: "Custom " env: "CUSTOM_TOKEN" # User-defined scheme name - Basic auth http-basic: scheme: basic # User-defined scheme name - Bearer token jwt-bearer: scheme: bearer ``` Configure authentication using custom HTTP headers, such as API keys or tokens. ```yaml auth-schemes: api-key: # User-defined scheme name name: "API Key Authentication" header: "X-API-Key" type: "string" prefix: "ApiKey " env: "MY_API_KEY" # SDK will auto-scan this environment variable ``` The name of the HTTP header to use for authentication. A descriptive name for this authentication scheme. The type of the header value. A prefix to prepend to the header value (e.g., `"Bearer "` or `"Token "`). Environment variable name containing the authentication value. When specified, the generated SDK will automatically scan for this environment variable at initialization. Configure HTTP Basic authentication using username and password credentials. ```yaml auth-schemes: basic-auth: # User-defined scheme name scheme: basic username: name: "Username" env: "BASIC_AUTH_USERNAME" # SDK will auto-scan this environment variable password: name: "Password" env: "BASIC_AUTH_PASSWORD" # SDK will auto-scan this environment variable ``` Must be set to `"basic"` for Basic authentication schemes. Configuration for the username credential. Custom parameter name for the username in the generated SDK. If not specified, defaults to `"username"`. Use this to provide more descriptive or domain-specific parameter names like `"clientId"`, `"userEmail"`, or `"merchantId"`. Configuration for the password credential. Custom parameter name for the password in the generated SDK. If not specified, defaults to `"password"`. Use this to provide more descriptive or domain-specific parameter names like `"clientSecret"`, `"apiKey"`, or `"merchantKey"`. Environment variable name that the SDK will automatically scan for the username or password value. When this environment variable is present, users don't need to explicitly provide the username parameter. Follow naming conventions like `YOUR_APP_USERNAME` or `SERVICE_CLIENT_ID`. Configure Bearer token authentication for API access. ```yaml auth-schemes: bearer-token: # User-defined scheme name scheme: bearer token: name: "Access Token" env: "BEARER_TOKEN" # SDK will auto-scan this environment variable ``` Must be set to `"bearer"` for Bearer token authentication schemes. Configuration for the bearer token. A descriptive name for the token. Environment variable name containing the bearer token. When specified, the generated SDK will automatically scan for this environment variable at initialization. For Fern Definition, you can configure OAuth authentication either in `generators.yml` or [directly in your `api.yml` file](/api-definitions/ferndef/authentication#oauth-client-credentials). For OpenAPI, [OAuth must be configured in `generators.yml`](/api-definitions/openapi/authentication#oauth-client-credentials). Configure OAuth 2.0 client credentials authentication. Optionally configure a `refresh-token` endpoint for token renewal without re-authentication. ```yaml title="generators.yml" maxLines=10 auth-schemes: my-oauth: # User-defined scheme name scheme: oauth type: client-credentials scopes: - "read:users" - "write:users" client-id-env: "OAUTH_CLIENT_ID" # SDK will auto-scan this environment variable client-secret-env: "OAUTH_CLIENT_SECRET" # SDK will auto-scan this environment variable token-prefix: "Bearer" token-header: "Authorization" get-token: endpoint: "auth.get_token" request-properties: client-id: "clientId" client-secret: "clientSecret" scopes: "scope" response-properties: access-token: "access_token" expires-in: "expires_in" refresh-token: "refresh_token" refresh-token: endpoint: "auth.refresh_token" request-properties: refresh-token: "refreshToken" response-properties: access-token: "access_token" expires-in: "expires_in" refresh-token: "refresh_token" ``` Must be set to `"oauth"` for OAuth authentication schemes. The OAuth 2.0 grant type. Currently only `"client-credentials"` is supported. OAuth scopes to request when obtaining access tokens (e.g., `"read:users"`, `"write:orders"`). Environment variable name containing the OAuth client ID. When specified, the generated SDK will automatically scan for this environment variable at initialization. Environment variable name containing the OAuth client secret. When specified, the generated SDK will automatically scan for this environment variable at initialization. Prefix added to the access token in the Authorization header (e.g., `"Bearer"` results in `"Authorization: Bearer "`). Useful when your API expects a custom format. HTTP header name used to send the access token. Defaults to `"Authorization"` but can be customized if your API uses a different header (e.g., `"X-API-Token"`). #### `get-token` Specifies the endpoint that exchanges client credentials for an access token. This endpoint is called automatically when the SDK client is initialized. ```yaml title="generators.yml" get-token: endpoint: "auth.get_token" request-properties: client-id: "clientId" client-secret: "clientSecret" response-properties: access-token: "access_token" expires-in: "expires_in" ``` The endpoint that issues access tokens, such as `'auth.get_token'`. Maps OAuth parameter names to your API's request field names. Use this when your token endpoint expects different field names than the OAuth standard (e.g., your API uses `clientId` instead of `client_id`). The request field name for the client ID in your API (e.g., `"clientId"`, `"client_id"`). The request field name for the client secret in your API (e.g., `"clientSecret"`, `"client_secret"`). The request field name for scopes in your API (e.g., `"scope"`, `"scopes"`). Maps your API's response field names to OAuth standard names. Use this when your API returns tokens with different field names (e.g., `accessToken` instead of `access_token`). The response field name for the access token in your API (e.g., `"accessToken"`, `"access_token"`). The response field name for token expiration time in seconds (e.g., `"expiresIn"`, `"expires_in"`). When present, the SDK automatically refreshes tokens before expiration. The response field name for the refresh token in your API (e.g., `"refreshToken"`, `"refresh_token"`). Required if using the `refresh-token` flow. #### `refresh-token` Specifies the endpoint that exchanges a refresh token for a new access token. When configured, the SDK automatically uses this endpoint to renew expired tokens without re-sending credentials. If not configured, the SDK will re-authenticate using `get-token` when tokens expire. ```yaml title="generators.yml" refresh-token: endpoint: "auth.refresh_token" request-properties: refresh-token: "refreshToken" response-properties: access-token: "access_token" expires-in: "expires_in" ``` The endpoint that refreshes access tokens (e.g., `"POST /oauth/refresh"` or `"auth.refreshToken"`). Maps OAuth parameter names to your API's request field names for the refresh flow. The request field name for the refresh token in your API (e.g., `"refreshToken"`, `"refresh_token"`). Maps your API's refresh response field names to OAuth standard names. The response field name for the new access token (e.g., `"accessToken"`, `"access_token"`). The response field name for the new token's expiration time in seconds (e.g., `"expiresIn"`, `"expires_in"`). The response field name if your API issues a new refresh token with each refresh (token rotation). ## `api` Defines the API specification (OpenAPI, AsyncAPI, etc.) and how to parse it. For Fern Definition, no API reference is needed – [Fern automatically detects your spec](/sdks/overview/project-structure#generatorsyml). ```yaml title="generators.yml" maxLines=10 api: settings: inline-path-parameters: true # Applies to all OpenAPI specs specs: - openapi: "./openapi.yml" namespace: "v1" settings: title-as-schema-name: true # Applies only to this OpenAPI spec - asyncapi: "./events.yml" namespace: "events" headers: Authorization: "Bearer ${API_TOKEN}" environments: production: "https://api.prod.com" staging: "https://api.staging.com" ``` Authentication configuration for the API. Global headers to include with all API requests. You can specify headers as simple string values or as objects with additional configuration for code generation. ```yaml title="generators.yml" api: headers: Authorization: "Bearer ${API_TOKEN}" X-App-Version: "1.0.0" ``` ```yaml title="generators.yml" api: - openapi: ./path/to/openapi headers: X-Version: # The variable name to use in generated SDK code. # If not specified, uses the header name. name: version # The type of the header value for code generation # (e.g., "string", "literal<'value'>", "number"). type: literal<"1234"> ``` Environment configurations for different deployment targets. Settings that apply to all specs of a given type (e.g., all OpenAPI specs). Can be overridden at the spec or generator level. Precedence: generator-level settings override spec-level settings, which override global settings. For example, use this to ensure consistent parsing behavior across all your OpenAPI specs. For available settings, see the [specification type](#specification-types) documentation below. ### Specification types Each specification type (OpenAPI, AsyncAPI, etc.) supports various configuration options including the spec file location, namespace, overrides, and type-specific settings. ```yaml title="generators.yml" api: specs: - openapi: "./openapi.yml" origin: "https://api.example.com/openapi.json" overlays: "./openapi-overlays.yml" overrides: "./openapi-overrides.yml" namespace: "v1" settings: title-as-schema-name: true inline-path-parameters: false inline-all-of-schemas: true prefer-undiscriminated-unions-with-literals: true filter: endpoints: ["POST /users", "GET /users/{id}"] example-generation: request: max-depth: 2 ``` Path to the OpenAPI specification file. URL of the API definition origin for pulling updates. For instructions on how to set up automatic syncing, refer to [Sync your OpenAPI specification](/learn/api-definitions/openapi/sync-your-open-api-specification). Path to an [OpenAPI Overlay](/learn/api-definitions/openapi/overlays) file. Overlays follow the [OpenAPI Overlay Specification](https://spec.openapis.org/overlay/v1.0.0.html) and are the recommended approach for customizing OpenAPI specifications. Path to OpenAPI overrides file. Consider using `overlays` instead for a standards-based approach. Namespace for the specification. Useful for configuring a [single package with multiple API versions](/api-definitions/overview/project-structure#option-2-namespace-based-versioning). OpenAPI-specific generation settings for this individual spec. To apply the same settings across all OpenAPI specs, use global [`api.settings`](/learn/sdks/reference/generators-yml#settings) instead. Whether to use the titles of schemas within an OpenAPI definition as the names of types within Fern. Whether to include path parameters within the generated in-lined request. Whether to inline `allOf` schemas during code generation. When true, Fern recursively visits `allOf` schema definitions and inlines them into the child schema. When false, `allOf` schemas are extended through inheritance. Enabling this setting allows child schemas to override parent property requirements. For example, a child schema can mark a parent's required property as optional. Without this setting, Fern ignores the child schema's optional declaration and preserves the parent schema's requirement instead. Whether to prefer undiscriminated unions with literals. Whether to only include schemas referenced by endpoints in the generated SDK (tree-shaking). Preserves nullable schemas in API definition settings. When false, nullable schemas are treated as optional. Enables parsing deep object query parameters. Controls whether references to nullable schemas are wrapped in optional types. When false, nullable references are treated as required fields that can be null. Controls whether optional schemas are coerced to nullable types during code generation. When false, optional and nullable are treated as distinct concepts. Enables exploring readonly schemas in OpenAPI specifications. Enables respecting forward compatible enums in OpenAPI specifications. Enables using the `bytes` type for binary responses. Defaults to file stream. The default encoding of form parameters. Options: `form`, `json`. Configure what `additionalProperties` should default to when not explicitly defined on a schema. If true, convert strings with format date to strings. If false, convert to dates. If true, preserve oneOf structures with a single schema. If false, unwrap them. Endpoints to include in the generated SDK (e.g., "POST /users"). Controls the maximum depth for which optional properties will have examples generated. A depth of 0 means no optional properties will have examples. Controls the maximum depth for which optional properties will have examples generated in responses. Controls whether enums are converted to literal types during code generation. When `false` (default), enums are preserved as enum types, maintaining the original enum structure from your OpenAPI specification. When `true`, enums are coerced to literal types, which can be useful for simpler type representations in generated code. Controls the naming convention for autogenerated request names. When enabled, places the verb before the noun in request names (e.g., `UsersListRequest` becomes `ListUsersRequest`), following more idiomatic naming patterns. Inlines type aliases to simplify your generated SDK. When enabled, reduces unnecessary type definitions by replacing simple aliases with their underlying types directly. Useful for OpenAPI specs with many primitive or simple type aliases. Set to `true` to inline all aliases, or use an object with an `except` array to preserve specific type aliases: ```yaml settings: # Inline all aliases resolve-aliases: true # Or preserve specific aliases resolve-aliases: except: - UserId - OrganizationId ``` When enabled, groups servers by host into unified environments, enabling APIs with multiple protocols (REST, WebSocket, etc.) to share environment configuration. Environment URL IDs use the server name, with path or protocol suffixes added only when needed to resolve collisions. ```yaml api: specs: - asyncapi: "./asyncapi.yml" origin: "https://api.example.com/asyncapi.json" overrides: "./asyncapi-overrides.yml" namespace: "events" settings: message-naming: "v2" title-as-schema-name: false respect-nullable-schemas: true ``` Path to the AsyncAPI specification file. URL of the API definition origin for pulling updates. Path to AsyncAPI overrides file. Namespace for the specification. Useful for configuring a [single package with multiple API versions](/api-definitions/overview/project-structure#option-2-namespace-based-versioning). AsyncAPI-specific generation settings for this individual spec. To apply the same settings across all AsyncAPI specs, use global [`api.settings`](/learn/sdks/reference/generators-yml#settings) instead. What version of message naming to use for AsyncAPI messages. Options: `v1`, `v2`. Whether to use the titles of schemas within an AsyncAPI definition as the names of types within Fern. Preserves nullable schemas in API definition settings. When false, nullable schemas are treated as optional. Controls the naming convention for autogenerated request names. When enabled, places the verb before the noun in request names (e.g., `UsersListRequest` becomes `ListUsersRequest`), following more idiomatic naming patterns. Controls whether references to nullable schemas are wrapped in optional types. When false, nullable references are treated as required fields that can be null. Controls whether optional schemas are coerced to nullable types during code generation. When false, optional and nullable are treated as distinct concepts. When enabled, groups servers by host into unified environments, enabling APIs with multiple protocols (REST, WebSocket, etc.) to share environment configuration. Environment URL IDs use the server name, with path or protocol suffixes added only when needed to resolve collisions. ```yaml title="generators.yml" api: specs: - proto: root: "./proto" target: "proto/service/v1/service.proto" local-generation: true ``` Path to the `.proto` directory root (e.g., `proto`). Must be specified up to where the package starts. For example, if your package is `package.test.v1` at the file path `protos/package/test/v1/test_file.proto`, the root should be `protos/` Path to the target `.proto` file (e.g., `proto/user/v1/user.proto`). Omit to generate docs for the entire root folder. Path to the overrides configuration file. Used for SDK generation only, not for documentation generation. Whether to compile `.proto` files locally. Defaults to remote generation (`false`). Path to the OpenRPC specification file. Path to OpenRPC overrides file. Namespace for the specification. ```yaml title="generators.yml" api: specs: conjure: "./conjure-api.yml" ``` Path to Conjure specification file. ## `whitelabel` Configuration for publishing generated SDKs without Fern branding. When enabled, removes all mentions of Fern from the generated code and allows publishing under your own brand. ```yaml title="generators.yml" whitelabel: github: username: "company-github-username" email: "my-email@example.com" token: "ghp_xxxxxxxxxxxx" ``` The GitHub username that will be used for committing and publishing the whitelabeled SDK code to GitHub repositories. This should be the username of the account that has write access to your target repositories. The email address associated with the GitHub account. This email will be used in Git commits when publishing the whitelabeled SDK code and should match the email configured in your GitHub account settings. A GitHub Personal Access Token (PAT) with appropriate permissions for repository access. The token should have `repo` scope permissions to allow reading from and writing to your repositories for publishing whitelabeled SDKs. ## `metadata` Package metadata like description and authors that gets included in all generated SDKs. Alternatively, you can [define metadata for individual SDKs](#metadata-2). ```yaml title="generators.yml" metadata: description: "My API SDK" authors: - name: "John Doe" email: "john@example.com" - name: "Jane Smith" email: "jane@example.com" ``` A brief description of the SDK that will be included in package metadata. This description helps users understand what your SDK does when they discover it in package repositories. ### `authors` A list of authors who will be credited in the generated SDK's package metadata. The full name of the author to be credited in the SDK package metadata. The email address of the author. This will be included in package metadata and may be used by package managers for contact information. ## `readme` Controls what goes into the generated README files across all SDKs, allowing you to customize the content and structure of your SDK documentation. ```yaml title="generators.yml" maxLines=10 readme: bannerLink: "https://example.com/banner" introduction: "Welcome to our API" apiReferenceLink: "https://docs.example.com" apiName: "Example Product" exampleStyle: "minimal" disabledSections: - "contributing" defaultEndpoint: method: "POST" path: "/users" stream: false customSections: - title: "Custom Section" language: "java" content: | This is a custom section. Latest package info is {{ group }}:{{ artifact }}:{{ version }}. - title: "Custom Section" language: "typescript" content: | Custom section for {{ packageName }} - title: "Another Custom Section" language: "typescript" content: | A second custom section for {{ packageName }} features: authentication: - method: "POST" path: "/auth/login" - "GET /auth/profile" users: - method: "GET" path: "/users" - method: "POST" path: "/users" ``` URL for a banner image or link that appears at the top of the README. Custom introduction text that appears at the beginning of the README. URL to your external API documentation or reference guide. Name of the API that appears in the README. Will appear as `Your Api Name SDK` or `Your Api Name API` throughout the README. Defaults to organization name if not set. Controls whether usage examples show only required parameters (`minimal`) or all parameters (`comprehensive`). Currently only supported for Java SDKs. Sections to disable in the README. Supported values: `"contributing"`. Organizes endpoints into named feature sections within the README. Each feature creates a dedicated section with example code snippets for the specified endpoints. Specifies which endpoint's code snippet to showcase as the primary example in the README. HTTP method of the default endpoint (e.g., `GET`, `POST`, `PUT`, `DELETE`). Endpoint path for the default example (e.g., `/users`, `/auth/login`). Whether the endpoint is a streaming endpoint. Defaults to `false`. Define a custom section in the generated README for a specific SDK. The title of the custom section as it will appear in the README. The target SDK language for this section. The custom section will only appear in README files generated for the specified language. The Markdown content of the custom section. You can use template variables in the format `{{ variable }}` that will be dynamically replaced with values specific to each SDK language when the README is generated. Available template variables by language: | Language | Variable | Description | | ---------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TypeScript | `packageName` | Name of your package, as specified in the [`package-name` field](/sdks/generators/typescript/configuration#package-name) | | Python | `packageName` | Name of your package, as specified in the [`package_name` field](/sdks/generators/python/configuration#package_name) | | Go | `owner` | The owner of your Go module | | Go | `repo` | The [repository](/sdks/generators/go/publishing#configure-output-location) where your Go module is published | | Go | `version` | SDK version | | Java | `group` | Maven `groupId` [from `coordinate` field](/sdks/generators/java/publishing#configure-maven-coordinate) | | Java | `artifact` | Maven `artifactId` [from `coordinate` field](/sdks/generators/java/publishing#configure-maven-coordinate) | | Java | `version` | SDK version | | C#/.NET | `packageName` | Name of your package, as specified in the [`package-name` field](/sdks/generators/csharp/configuration#package-name) | | PHP | `packageName` | Name of your package, as specified in the [`package-name` field](/sdks/generators/php/configuration#package-name) | | Ruby | `packageName` | Name of your package, as specified in the [`package-name` field](/sdks/generators/ruby/configuration#package-name) | | Swift | `gitUrl` | The [URL](/sdks/generators/swift/publishing#verify-package-availability) where your Swift package is published. For example, `https://github.com/fern-api/basic-swift-sdk` | | Swift | `minVersion` | SDK version | ## `default-group` Which generator group to use when none is specified. ```yaml default-group: "production" ``` ## `aliases` Define shortcuts that map to multiple generator groups, allowing you to run several groups with a single command. When you run `fern generate --group `, all groups in the alias run in parallel. You can also set an alias as your `default-group`. ```yaml title="generators.yml" {1-4} aliases: all: ["php-sdk", "ts-sdk", "go-sdk"] frontend: ["ts-sdk"] backend: ["php-sdk", "go-sdk"] groups: php-sdk: generators: - name: fernapi/fern-php-sdk version: 1.0.0 ts-sdk: generators: - name: fernapi/fern-typescript-sdk version: 1.0.0 go-sdk: generators: - name: fernapi/fern-go-sdk version: 1.0.0 ``` A map where each key is an alias name and the value is a list of group names. Each group name must reference a group defined in the `groups` section. ## `groups` Organizes user-defined sets of generators, typically grouped by environment (like "production", "staging") or language (like "typescript", "python"). You can also create [aliases](#aliases) to run multiple groups with a single command. ```yaml title="generators.yml" maxLines=10 groups: typescript-sdk: # User-defined name audiences: ["external"] generators: - name: fernapi/fern-typescript-sdk version: 0.9.0 output: location: npm package-name: "@myorg/api-sdk" token: "${NPM_TOKEN}" github: repository: your-organization/company-typescript mode: "pull-request" metadata: description: "TypeScript SDK for MyAPI" authors: - name: "SDK Team" email: "sdk@myorg.com" reviewers: teams: - name: "sdk-team" ``` Target audiences for this generator group (e.g., "external", "internal") ### `reviewers` Set code reviewers for an individual SDK. Alternatively, you can [configure reviewers globally for all SDKs](#reviewers-4). ```yaml title="generators.yml" reviewers: teams: - name: "sdk-team" - name: "api-team" users: - name: "john-doe" - name: "jane-smith" ``` GitHub team names that should review generated code. GitHub users that should review generated code. Name of a GitHub team. Name of a GitHub user. ### `generators` Generator settings for a specific group. ```yaml title="generators.yml" groups: typescript-sdk: # User-defined name audiences: ["external"] generators: - name: fernapi/fern-typescript-sdk version: 0.9.0 smart-casing: true ``` The Fern generator package name (e.g., fernapi/fern-typescript-sdk) Specific version of the generator to use Enables intelligent case conversion that preserves numbers and common programming patterns: * Numbers stay intact (e.g., `v2` instead of `v_2`, `getUsersV2` instead of `getUsersV_2`) * Initialisms are preserved (e.g., `CustomerID` instead of `CustomerId`) * Acronyms remain correct (e.g., `HTTPSConnection` stays `HTTPSConnection`) #### `config` Language-specific configuration options. ```yaml title="generators.yml" groups: ts-sdk: # Typescript SDK group generators: - name: fernapi/fern-typescript-sdk version: 3.43.13 config: # TypeScript-specific config options namespaceExport: AcmePayments noSerdeLayer: false ``` #### `output` Where to publish the generated SDK. ```yaml title="generators.yml" groups: typescript-sdk: # User-defined name audiences: ["external"] generators: - name: fernapi/fern-typescript-sdk version: 0.9.0 output: location: npm package-name: "@myorg/api-sdk" token: "${NPM_TOKEN}" ``` Publish TypeScript SDKs to the npm registry. ```yaml title="generators.yml" output: location: npm package-name: "@myorg/api-sdk" token: "${NPM_TOKEN}" ``` Set to "npm" for NPM publishing Custom NPM registry URL NPM package name (e.g., "@myorg/api-sdk") NPM authentication token for publishing Publish Java SDKs to Maven repository. ```yaml title="generators.yml" output: location: maven coordinate: "com.myorg:api-sdk" username: "${MAVEN_USERNAME}" password: "${MAVEN_PASSWORD}" signature: keyId: "ABC123" password: "${GPG_PASSWORD}" secretKey: "${GPG_SECRET_KEY}" ``` Set to "maven" for Maven publishing Maven repository URL (optional, defaults to Maven Central) Maven artifact coordinate in "groupId:artifactId" format Repository authentication username Repository authentication password GPG signature configuration for package signing GPG key ID for package signing GPG key password GPG secret key content Publish Python SDKs to Python Package Index. ```yaml title="generators.yml" output: location: pypi package-name: "myorg-api-sdk" token: "${PYPI_TOKEN}" metadata: keywords: ["api", "sdk", "client"] documentation-link: "https://docs.myorg.com" homepage-link: "https://myorg.com" ``` Set to "pypi" for PyPI publishing Custom PyPI registry URL (optional, defaults to PyPI) Python package name (e.g., "myorg-api-sdk") PyPI authentication token for publishing PyPI username (alternative to token authentication) PyPI password (alternative to token authentication) Additional PyPI-specific metadata for the package Package keywords for PyPI search and discovery Link to package documentation Link to project homepage Publish .NET SDKs to NuGet repository. ```yaml title="generators.yml" output: location: nuget package-name: "MyOrg.ApiSdk" api-key: "${NUGET_API_KEY}" ``` Set to "nuget" for NuGet publishing Custom NuGet feed URL (optional, defaults to nuget.org) NuGet package name (e.g., "MyOrg.ApiSdk") NuGet API key for publishing to the feed Publish Ruby SDKs to RubyGems registry. ```yaml title="generators.yml" output: location: rubygems package-name: "myorg_api_sdk" api-key: "${RUBYGEMS_API_KEY}" ``` Set to "rubygems" for RubyGems publishing Custom RubyGems registry URL (optional, defaults to rubygems.org) Ruby gem package name (e.g., "myorg\_api\_sdk") RubyGems API key for publishing (requires "Push rubygem" permission) > **Note**: RubyGems API keys need "Push rubygem" permission and ideally "index" and "yank rubygem" permissions. If MFA is enabled, ensure MFA settings don't require MFA for API key usage. Publish API collections to Postman workspace. ```yaml title="generators.yml" output: location: postman api-key: "${POSTMAN_API_KEY}" workspace-id: "12345678-1234-1234-1234-123456789abc" collection-id: "87654321-4321-4321-4321-cba987654321" ``` Set to "postman" for Postman publishing Postman API key for workspace access Target Postman workspace ID where collection will be published Existing collection ID to update (creates new collection if not specified) Save generated SDKs to local file system instead of publishing. ```yaml title="generators.yml" output: location: local-file-system path: "./generated-sdks/typescript" ``` Set to "local-file-system" for local output Local directory path where generated files will be saved #### `github` Specify how your SDKs are generated in GitHub using the `github` configuration. Designate the `mode` to specify how Fern handles your code changes. For cloud generation, specify the GitHub repository using `repository`. For [self-hosted generation](/learn/sdks/deep-dives/self-hosted), use `uri` and `token` instead. Make sure the [Fern GitHub app](https://github.com/apps/fern-api) is installed on your destination repository (not required for self-hosted generation) Fern generates your code, commits it to main, and tags a new release. ```yml {6-17} groups: ts-sdk: generators: - name: fernapi/fern-typescript-sdk ... github: repository: "your-org/your-repo-name" mode: "release" ``` Name of your repository in GitHub. Name of your branch in GitHub. Software license for the generated SDK. Specify which teams and users should review generated code. See [reviewers configuration](#reviewers-1). Fern generates your code, commits to a new branch, and opens a PR for review. To publish, you must merge the PR and tag a GitHub release. ```yml {6-8} groups: ts-sdk: generators: - name: fernapi/fern-typescript-sdk ... github: repository: "your-org/your-repo-name" mode: "pull-request" ``` Name of your repository in GitHub. Name of your branch in GitHub. Software license for the generated SDK. Specify which teams and users should review generated code. See [reviewers configuration](#reviewers-1). Fern generates your code and pushes it to the branch you specify. ```yml {6-8} groups: ts-sdk: generators: - name: fernapi/fern-typescript-sdk ... github: repository: "your-org/your-repo-name" mode: "push" branch: "your-branch-name" # required for `mode: push` ``` Name of your repository in GitHub. Name of your branch in GitHub. Software license for the generated SDK. Specify which teams and users should review generated code. See [reviewers configuration](#reviewers-1). For [self-hosted SDK generation](/learn/sdks/deep-dives/self-hosted), configure the `github` property with `uri` and `token` instead of `repository`. ```yml {6-10} groups: ts-sdk: generators: - name: fernapi/fern-typescript-sdk ... github: uri: "https://github.com/your-org/your-repo-name" token: "${GITHUB_TOKEN}" mode: "push" branch: "main" ``` Full URL to your GitHub repository (e.g., `https://github.com/your-org/your-repo`). GitHub Personal Access Token with repository write permissions. Use an environment variable reference (e.g., `${GITHUB_TOKEN}`). How to publish changes: `push` commits directly to the branch, `pull-request` opens a PR for review. Target branch for commits or pull requests. #### `metadata` Specify metadata for an individual SDK. Alternatively, you can [configure metadata globally for all SDKs](#metadata). ```yml title="generators.yml" {6-10} groups: ts-sdk: generators: - name: fernapi/fern-typescript-sdk ... metadata: package-description: "Description of your SDK" email: "sdk@example.com" reference-url: "https://docs.example.com/sdks" license: "MIT" ``` A brief description of what your generated SDK does and its key features. This appears in the `package.json` description field and package registry listings. Contact email for the package maintainer or support team. URL pointing to comprehensive documentation, API reference, or getting started guide for the SDK. Name of the individual developer, team, or organization that created and maintains the SDK. Software license for the generated SDK. #### `snippets` Configures snippets for a particular generator. ```yml title="generators.yml" {6-8} groups: ts-sdk: generators: - name: fernapi/fern-typescript-sdk ... snippets: path: "./snippets" ``` The path to the generated snippets file. #### Override API authentication settings Override authentication settings in your API spec for a specific SDK using the `api` configuration. Reference a pre-defined authentication scheme by name. ```yml title="generators.yml" {6-7} groups: ts-sdk: generators: - name: fernapi/fern-typescript-sdk ... api: auth: "bearer-token" ``` The authentication scheme to use. Can be either a string reference (`"bearer-token"`) or scheme object (`scheme: "bearer-token"`). Allow users to authenticate with any of several methods: ```yml title="generators.yml" {6-12} groups: ts-sdk: generators: - name: fernapi/fern-typescript-sdk ... api: auth: any: - "api-key" - "bearer-token" - scheme: "oauth-flow" ``` A list of authentication schemes where users can choose any one method. Each item can be either a string reference (`"api-key"`) or scheme object (`scheme: "api-key"`). Define a custom authentication schemes using `auth-schemes`. You define a name for your custom scheme, and then specify the authentication method (`header`, `basic`, `bearer`, or `oauth`). ```yml title="generators.yml" {8-12} groups: ts-sdk: generators: - name: fernapi/fern-typescript-sdk ... api: auth-schemes: bearer: # User-defined name for your auth schema scheme: "bearer" token: name: "token" env: "BEARER_TOKEN" ``` Configure authentication using custom HTTP headers, such as API keys or tokens. ```yaml auth-schemes: api-key: # User-defined scheme name name: "API Key Authentication" header: "X-API-Key" type: "string" prefix: "ApiKey " env: "MY_API_KEY" # SDK will auto-scan this environment variable ``` The name of the HTTP header to use for authentication. A descriptive name for this authentication scheme. The type of the header value. A prefix to prepend to the header value (e.g., `"Bearer "` or `"Token "`). Environment variable name containing the authentication value. When specified, the generated SDK will automatically scan for this environment variable at initialization. Configure HTTP Basic authentication using username and password credentials. ```yaml auth-schemes: basic-auth: # User-defined scheme name scheme: basic username: name: "Username" env: "BASIC_AUTH_USERNAME" # SDK will auto-scan this environment variable password: name: "Password" env: "BASIC_AUTH_PASSWORD" # SDK will auto-scan this environment variable ``` Must be set to `"basic"` for Basic authentication schemes. Configuration for the username credential. Custom parameter name for the username in the generated SDK. If not specified, defaults to `"username"`. Use this to provide more descriptive or domain-specific parameter names like `"clientId"`, `"userEmail"`, or `"merchantId"`. Configuration for the password credential. Custom parameter name for the password in the generated SDK. If not specified, defaults to `"password"`. Use this to provide more descriptive or domain-specific parameter names like `"clientSecret"`, `"apiKey"`, or `"merchantKey"`. Environment variable name that the SDK will automatically scan for the username or password value. When this environment variable is present, users don't need to explicitly provide the username parameter. Follow naming conventions like `YOUR_APP_USERNAME` or `SERVICE_CLIENT_ID`. Configure Bearer token authentication for API access. ```yaml auth-schemes: bearer-token: # User-defined scheme name scheme: bearer token: name: "Access Token" env: "BEARER_TOKEN" # SDK will auto-scan this environment variable ``` Must be set to `"bearer"` for Bearer token authentication schemes. Configuration for the bearer token. A descriptive name for the token. Environment variable name containing the bearer token. When specified, the generated SDK will automatically scan for this environment variable at initialization. For Fern Definition, you can configure OAuth authentication either in `generators.yml` or [directly in your `api.yml` file](/api-definitions/ferndef/authentication#oauth-client-credentials). For OpenAPI, [OAuth must be configured in `generators.yml`](/api-definitions/openapi/authentication#oauth-client-credentials). Configure OAuth 2.0 client credentials authentication. Optionally configure a `refresh-token` endpoint for token renewal without re-authentication. ```yaml title="generators.yml" maxLines=10 auth-schemes: my-oauth: # User-defined scheme name scheme: oauth type: client-credentials scopes: - "read:users" - "write:users" client-id-env: "OAUTH_CLIENT_ID" # SDK will auto-scan this environment variable client-secret-env: "OAUTH_CLIENT_SECRET" # SDK will auto-scan this environment variable token-prefix: "Bearer" token-header: "Authorization" get-token: endpoint: "auth.get_token" request-properties: client-id: "clientId" client-secret: "clientSecret" scopes: "scope" response-properties: access-token: "access_token" expires-in: "expires_in" refresh-token: "refresh_token" refresh-token: endpoint: "auth.refresh_token" request-properties: refresh-token: "refreshToken" response-properties: access-token: "access_token" expires-in: "expires_in" refresh-token: "refresh_token" ``` Must be set to `"oauth"` for OAuth authentication schemes. The OAuth 2.0 grant type. Currently only `"client-credentials"` is supported. OAuth scopes to request when obtaining access tokens (e.g., `"read:users"`, `"write:orders"`). Environment variable name containing the OAuth client ID. When specified, the generated SDK will automatically scan for this environment variable at initialization. Environment variable name containing the OAuth client secret. When specified, the generated SDK will automatically scan for this environment variable at initialization. Prefix added to the access token in the Authorization header (e.g., `"Bearer"` results in `"Authorization: Bearer "`). Useful when your API expects a custom format. HTTP header name used to send the access token. Defaults to `"Authorization"` but can be customized if your API uses a different header (e.g., `"X-API-Token"`). ##### `get-token` Specifies the endpoint that exchanges client credentials for an access token. This endpoint is called automatically when the SDK client is initialized. ```yaml title="generators.yml" get-token: endpoint: "auth.get_token" request-properties: client-id: "clientId" client-secret: "clientSecret" response-properties: access-token: "access_token" expires-in: "expires_in" ``` The endpoint that issues access tokens, such as `'auth.get_token'`. Maps OAuth parameter names to your API's request field names. Use this when your token endpoint expects different field names than the OAuth standard (e.g., your API uses `clientId` instead of `client_id`). The request field name for the client ID in your API (e.g., `"clientId"`, `"client_id"`). The request field name for the client secret in your API (e.g., `"clientSecret"`, `"client_secret"`). The request field name for scopes in your API (e.g., `"scope"`, `"scopes"`). Maps your API's response field names to OAuth standard names. Use this when your API returns tokens with different field names (e.g., `accessToken` instead of `access_token`). The response field name for the access token in your API (e.g., `"accessToken"`, `"access_token"`). The response field name for token expiration time in seconds (e.g., `"expiresIn"`, `"expires_in"`). When present, the SDK automatically refreshes tokens before expiration. The response field name for the refresh token in your API (e.g., `"refreshToken"`, `"refresh_token"`). Required if using the `refresh-token` flow. ##### `refresh-token` Specifies the endpoint that exchanges a refresh token for a new access token. When configured, the SDK automatically uses this endpoint to renew expired tokens without re-sending credentials. If not configured, the SDK will re-authenticate using `get-token` when tokens expire. ```yaml title="generators.yml" refresh-token: endpoint: "auth.refresh_token" request-properties: refresh-token: "refreshToken" response-properties: access-token: "access_token" expires-in: "expires_in" ``` The endpoint that refreshes access tokens (e.g., `"POST /oauth/refresh"` or `"auth.refreshToken"`). Maps OAuth parameter names to your API's request field names for the refresh flow. The request field name for the refresh token in your API (e.g., `"refreshToken"`, `"refresh_token"`). Maps your API's refresh response field names to OAuth standard names. The response field name for the new access token (e.g., `"accessToken"`, `"access_token"`). The response field name for the new token's expiration time in seconds (e.g., `"expiresIn"`, `"expires_in"`). The response field name if your API issues a new refresh token with each refresh (token rotation). ### `reviewers` Set code reviewers globally for all SDKs. Alternatively, you can [configure reviewers for individual SDKs](#reviewers). ```yaml title="generators.yml" reviewers: teams: - name: "sdk-team" - name: "api-team" users: - name: "john-doe" - name: "jane-smith" ``` GitHub team names that should review generated code. GitHub users that should review generated code. Name of a GitHub team. Name of a GitHub user.