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.
To enable intelligent YAML validation and autocompletion in your editor, add a schema directive to the top of your generators.yml file.
auth-schemesDefine authentication methods for your SDKs and the API Explorer that your endpoints can reference. Authentication schemes defined in generators.yml take precedence over authentication schemes defined in your spec.
After defining an authentication scheme, you must use api.auth to apply it as the default across all endpoints. Alternatively, you can define authentication for individual SDKs if you need different auth behavior per language.
Choose from custom headers (API keys), HTTP Basic, Bearer token, or OAuth 2.0 authentication:
Configure authentication using custom HTTP headers, such as API keys or tokens.
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.
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.
Use when your API expects only one half of the basic auth credential pair. When true, the field is removed from the generated SDK’s public API. The omitted field is treated as an empty string when encoding the Authorization header (omitting password produces base64("username:"); omitting username produces base64(":password")). When both are omitted, the Authorization header is skipped entirely.
Configure Bearer token authentication for API access.
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 OpenAPI, OAuth must be configured in generators.yml.
Configure OAuth 2.0 client credentials authentication. Optionally configure a refresh-token endpoint for token renewal without re-authentication.
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 <token>"). 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-tokenSpecifies the endpoint that exchanges client credentials for an access token. This endpoint is called automatically when the SDK client is initialized.
The endpoint that issues access tokens, such as 'auth.get_token' or 'POST /oauth/token'. If your API uses namespaces, prefix with the namespace and :: (e.g., 'payments::POST /oauth/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-tokenSpecifies 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.
The endpoint that refreshes access tokens (e.g., "POST /oauth/refresh" or "auth.refreshToken"). If your API uses namespaces, prefix with the namespace and :: (e.g., "payments::POST /oauth/refresh").
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).
apiDefines the API specification (OpenAPI, AsyncAPI, etc.) and how to parse it.
Sets the default authentication scheme for all endpoints. The value must reference a scheme name defined in auth-schemes. This overrides any security schemes defined in your OpenAPI spec.
With this configuration, all generated SDKs will require authentication using the BearerAuth scheme:
You can also override authentication for individual generators using the generator-level api.auth setting.
Global headers to include with all API requests. This is an alternative to configuring global headers in your OpenAPI spec. You can specify headers as simple string values or as objects with additional configuration for code generation.
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 documentation below.
Each specification type (OpenAPI, AsyncAPI, etc.) supports various configuration options including the spec file location, namespace, overrides, and type-specific settings.
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.
Path to an OpenAPI Overlay file. Overlays follow the OpenAPI Overlay Specification and are the recommended approach for customizing OpenAPI specifications.
Path to an OpenAPI overrides file, or a list of paths to multiple override files applied sequentially. Consider using overlays instead for a standards-based approach.
Namespace for the specification. Useful for configuring a single package with multiple API versions.
OpenAPI-specific generation settings for this individual spec. To apply the same settings across all OpenAPI specs, use global api.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.
Filter to apply to the OpenAPI specification. Use this to limit which endpoints are included in the generated SDK or API Reference docs based on their paths.
For tag-based filtering instead of path-based filtering, use audiences at the group level.
Endpoints to include in the generated SDK. Specify endpoints in the format METHOD /path (e.g., POST /users, GET /users/{id}). Only the listed endpoints will be included in the generated SDK; all other endpoints will be excluded. If your API uses namespaces, prefix with the namespace and :: (e.g., payments::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:
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.
Path to the AsyncAPI specification file.
URL of the API definition origin for pulling updates.
Path to an AsyncAPI overrides file, or a list of paths to multiple override files applied sequentially.
Namespace for the specification. Useful for configuring a single package with multiple API versions.
AsyncAPI-specific generation settings for this individual spec. To apply the same settings across all AsyncAPI specs, use global api.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.
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, or a list of paths to multiple override files applied sequentially. Used for SDK generation only, not for documentation generation.
Whether to compile .proto files locally. Defaults to remote generation (false). When enabled, you must have buf installed on your machine or in your CI/CD environment (e.g., GitHub Actions).
Path to the OpenRPC specification file.
Path to an OpenRPC overrides file, or a list of paths to multiple override files applied sequentially.
Namespace for the specification.
Path to Conjure specification file.
whitelabelConfiguration 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.
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.
metadataPackage metadata like description and authors that gets included in all generated SDKs. Alternatively, you can define metadata for individual SDKs.
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.
authorsA 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.
readmeControls what goes into the generated README files across all SDKs, allowing you to customize the content and structure of your SDK documentation.
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. File an issue to request additional languages.
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:
default-groupWhich generator group to use when none is specified.
autoreleaseEnable or disable Fern Autorelease globally for automated SDK releases. Alternatively, you can configure autorelease for individual SDKs.
Set to true to enable Autorelease, false to disable it. Per-generator settings override this global configuration.
replayOverride Fern Replay behavior. Replay runs based on your organization’s configuration; use this setting to disable it for all generators in this generators.yml.
Set to false to skip Replay for all SDK generations in this generators.yml, even if Replay is enabled for your organization.
aliasesDefine shortcuts that map to multiple generator groups, allowing you to run several groups with a single command. When you run fern generate --group <alias>, all groups in the alias run in parallel. You can also set an alias as your default-group.
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.
groupsOrganizes user-defined sets of generators, typically grouped by environment (like “production”, “staging”) or language (like “typescript”, “python”). You can also create aliases to run multiple groups with a single command.
Filter which API elements are included in generated SDKs on audience tags. Only endpoints, schemas, and properties tagged with the specified audiences in your API spec will be included. Without this filter, all endpoints are included regardless of their audience tags.
To use audiences, first tag your API elements with x-fern-audiences in OpenAPI, then specify which audiences to include here.
For OpenAPI, you can also configure path-based filtering at the spec level using settings.filter.
reviewersSet code reviewers for an individual SDK. Alternatively, you can configure reviewers globally for all SDKs.
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.
generatorsGenerator settings for a specific group.
The Fern generator package name (e.g., fernapi/fern-typescript-sdk). Mutually exclusive with image.
Specific version of the generator to use
Enables intelligent case conversion that preserves numbers and common programming patterns:
v2 instead of v_2, getUsersV2 instead of getUsersV_2)CustomerID instead of CustomerId)HTTPSConnection stays HTTPSConnection)Use image instead of name to pull the generator from a custom container registry during self-hosted generation (remote generation doesn’t support custom registries). Mutually exclusive with name.
The CLI constructs the full image reference as {registry}/{name}:{version} when pulling. For example, with registry: ghcr.io/your-org, name: fern-python-sdk, and version: 4.0.0, the CLI pulls ghcr.io/your-org/fern-python-sdk:4.0.0.
A recognized Fern generator name (e.g., fern-python-sdk). Required for IR version resolution.
The container registry hostname and optional namespace (e.g., ghcr.io/your-org). The CLI constructs the full image reference as {registry}/{name}:{version} when pulling. For example, with registry: ghcr.io/your-org, name: fern-python-sdk, and version: 4.0.0, the CLI pulls ghcr.io/your-org/fern-python-sdk:4.0.0.
configLanguage-specific configuration options.
outputWhere to publish the generated SDK.
Publish TypeScript SDKs to the npm registry.
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.
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.
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.
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.
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.
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.
Set to “local-file-system” for local output
Local directory path where generated files will be saved
githubSpecify 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, use uri and token instead.
Fern generates your code, commits it to the default branch (or the branch you specify), and tags a new release.
Name of your repository in GitHub.
If specified, Fern commits and tags the release on this branch instead of the default branch. The branch must already exist. Use this to publish versioned SDKs (e.g., v1 and v2) from a single repo.
Software license for the generated SDK.
Specify which teams and users should review generated code. See reviewers configuration.
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.
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.
Fern generates your code and pushes it to the branch you specify.
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.
For self-hosted SDK generation, configure the github property with uri and token instead of repository.
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.
metadataSpecify metadata for an individual SDK. Alternatively, you can configure metadata globally for all SDKs.
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.
autoreleaseEnable or disable Fern Autorelease for an individual SDK. Alternatively, you can configure autorelease globally for all SDKs.
Set to true to enable Autorelease for this generator, false to disable it. Per-generator settings override the global autorelease configuration.
snippetsConfigures snippets for a particular generator.
The path to the generated snippets file.
Override authentication settings for a specific SDK using the api configuration.
Reference a pre-defined authentication scheme by name.
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:
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).
Configure authentication using custom HTTP headers, such as API keys or tokens.
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.
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.
Use when your API expects only one half of the basic auth credential pair. When true, the field is removed from the generated SDK’s public API. The omitted field is treated as an empty string when encoding the Authorization header (omitting password produces base64("username:"); omitting username produces base64(":password")). When both are omitted, the Authorization header is skipped entirely.
Configure Bearer token authentication for API access.
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 OpenAPI, OAuth must be configured in generators.yml.
Configure OAuth 2.0 client credentials authentication. Optionally configure a refresh-token endpoint for token renewal without re-authentication.
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 <token>"). 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-tokenSpecifies the endpoint that exchanges client credentials for an access token. This endpoint is called automatically when the SDK client is initialized.
The endpoint that issues access tokens, such as 'auth.get_token' or 'POST /oauth/token'. If your API uses namespaces, prefix with the namespace and :: (e.g., 'payments::POST /oauth/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-tokenSpecifies 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.
The endpoint that refreshes access tokens (e.g., "POST /oauth/refresh" or "auth.refreshToken"). If your API uses namespaces, prefix with the namespace and :: (e.g., "payments::POST /oauth/refresh").
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).
reviewersSet code reviewers globally for all SDKs. Alternatively, you can configure reviewers for individual SDKs.
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.