You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When enabled, allows handling of additional properties not explicitly defined in the API specification. This provides flexibility for APIs that may include extra fields in responses.
Customizes the name of the base API exception class that all API-specific exceptions will inherit from. This allows you to define a custom base exception class name for better integration with your existing error handling patterns.
Specifies the name of the base exception class that all generated exceptions will inherit from. This provides a common parent class for all SDK exceptions, enabling consistent exception handling patterns.
Customizes the name of the pagination helper class used for handling paginated API responses. This allows you to specify a custom name that fits your naming conventions.
When enabled, generates enum types that can handle unknown values gracefully. This allows the SDK to process new enum values that may be added to the API without breaking existing client code, improving forward compatibility.
When enabled, generates code with explicit namespace declarations throughout the SDK. This can help avoid naming conflicts and improve code clarity in larger projects.
Sets the name of the exported client class that will be used in code examples and documentation. This is useful for customizing how the client appears in generated documentation.
When enabled, generates specific error type classes for different API errors. This provides strongly-typed error handling instead of using generic exception types.
When enabled, includes built-in exception handling utilities in the generated SDK. This provides convenience methods for common error handling scenarios.
When enabled, path parameters are included as properties in the request object instead of being passed as separate method parameters. This creates a more unified request structure where all parameters are grouped together.
Specifies a list of types that should be generated using ReadOnlyMemory<T> instead of regular arrays or collections. This can improve performance for large data transfers by reducing memory allocations.
Controls the access modifier for the root client class. Use 'public' to make the client accessible from other assemblies, or 'internal' to restrict access within the same assembly.
When enabled, places core SDK classes (like base client classes and utilities) in the root namespace instead of nested namespaces. This can simplify imports for commonly used types.
When enabled, generates discriminated union types for API responses that can contain multiple different object types. This provides type-safe handling of polymorphic responses.
When enabled, ensures that all required properties are always included in API requests, even if they have default values or are otherwise optional in the implementation.
Customizes the name of the client constructor function. This allows you to specify a custom name for the function that users will call to create a new instance of the client.
Sets the name of the exported client that will be used in code snippets and documentation examples. This is useful for customizing how the client appears in generated documentation.
When enabled, includes legacy client options for backward compatibility with older versions of the SDK. This is useful for maintaining compatibility when upgrading SDK versions.
Controls whether file upload properties are generated as inline request properties instead of separate parameters. When enabled, file upload fields become part of the request struct rather than being passed as individual function parameters.
When enabled, path parameters are inlined into request types rather than being passed as separate function parameters. This creates a more unified request structure where path parameters are included in the request object.
Controls the organization of the generated package structure. Choose 'flat' for a flatter package structure with fewer nested directories, or 'nested' for a more hierarchical organization that mirrors your API structure.
Specifies the package name for the generated Go code. This determines the package declaration that will appear at the top of generated Go files and affects how users import the SDK.
Controls the union type generation strategy. Use 'v0' for the legacy union implementation or 'v1' for the newer, more robust union handling approach that provides better type safety and discriminated union support.
When enabled, uses `io.Reader` interface for handling byte request bodies instead of byte slices. This is more memory-efficient for large payloads and follows Go best practices for streaming data.
Customizes the name of the base API exception class that all API-specific exceptions will extend. This allows you to define a custom base exception class name for better integration with your existing error handling patterns.
Specifies the name of the base exception class that all generated exceptions will inherit from. This provides a common parent class for all SDK exceptions, enabling consistent exception handling patterns.
When enabled, disables validation checks in builder patterns for required properties. This removes compile-time checks that ensure all required fields are set before building an object, providing more flexibility but less safety.
When enabled, generates enum classes that can handle unknown values gracefully. This allows the SDK to process new enum values that may be added to the API without breaking existing client code, improving forward compatibility.
When enabled, generates inline types for nested schemas instead of creating separate classes. This results in cleaner type definitions where nested objects are defined within their parent types, reducing the number of generated files.
When enabled, generates unknown or untyped properties as structured JSON objects instead of raw Object types. This provides better type safety and easier manipulation of dynamic JSON content while maintaining flexibility for unknown data structures.
Controls whether file upload properties are generated as inline request properties instead of separate method parameters. When enabled, file fields become part of the request object rather than being passed as individual function arguments.
When enabled, path parameters are included as properties in the request object instead of being passed as separate method parameters. This creates a more unified request structure where all parameters are grouped together.
Controls Jackson's JSON serialization behavior for optional fields. Use 'non-empty' to exclude null and empty values, or 'non-absent' to only exclude null values while preserving empty collections and strings.
Determines the organization of generated Java packages. Choose 'nested' for a hierarchical package structure that mirrors your API organization, or 'flat' for a simpler structure with fewer nested packages.
Provides a description of the SDK package that will appear in package metadata and documentation. This helps users understand what the SDK is for and its purpose.
Sets the reference URL (typically the API documentation or project website) that will be included in the package metadata for users to find additional information.
Allows customization of the generated `composer.json` file contents. You can specify additional metadata, dependencies, or configuration that will be merged into the package's composer configuration file.
When enabled, path parameters are included as properties in the request class instead of being passed as separate method parameters. This creates a more unified request structure where all parameters are grouped together in the request object.
Specifies the PHP namespace for all generated code. This determines the namespace hierarchy that users will use when importing and using the SDK classes.
Sets the name of the PHP package as it will appear in Composer and Packagist. This is the name users will use to install the SDK via Composer (e.g., `composer require your/package-name`).
Specifies the directory path where the generated SDK source files should be placed. This determines the file system location of the generated PHP code relative to the output directory.
Controls the access level of generated class properties. When set to 'public', properties are public and getter/setter methods are omitted. When set to 'private', properties are private and getter/setter methods are generated for encapsulation.
0 commit comments