This guide describes the process of generating an API client to access the VC Platform API from your custom application.
!!! note Platform Manager REST Client offers generated REST API methods that make it easy to interact with the existing VirtoCommerce Platform API.
- .NET Core 6.0, particularly if you are using MacOS or Linux.
To enable TypeScript API client generation in your project:
- Add dependencies to your project:
Using command
yarn add @vc-shell/api-client-generator cross-env
cross-env
runs scripts that set and use environment variables across platforms.
Manually
Add the dependencies to your project's package.json:
{
...
"devDependencies": {
...
"@vc-shell/api-client-generator": "latest",
"cross-env": "latest",
...
}
}
-
Configure client generation in your project. Inside your project's package.json file, add a
"generate-api-client"
command to the list of scripts:{ "scripts": { ... "generate-api-client": cross-env api-client-generator --APP_PLATFORM_MODULES='[Virtocommerce.MarketplaceVendor,Virtocommerce.Catalog,Virtocommerce.Orders]' --APP_API_CLIENT_DIRECTORY=./src/api_client/ } }
The options are listed in the table below:
Options Description Example --APP_PLATFORM_MODULES
Platform modules to generate API client.
{==string[]==}
Customize the--APP_PLATFORM_MODULES
list
to match your project's requirements.--APP_PLATFORM_MODULES='[Virtocommerce.MarketplaceVendor,Virtocommerce.Orders,Virtocommerce.Catalog]'
--APP_API_CLIENT_DIRECTORY
Output directory for generated API clients.
{==string==}--APP_API_CLIENT_DIRECTORY=./src/api_client/
--APP_PLATFORM_URL
Platform URL to obtain client API configs.
{==string==}--APP_PLATFORM_URL=https://vcmp-dev.govirto.com/
--APP_PACKAGE_NAME
Package name for generated API clients.
{==string==}--APP_PACKAGE_NAME=@api-client
--APP_PACKAGE_VERSION
Package version for generated API clients.
{==string==}--APP_PACKAGE_VERSION=1.1.0
--APP_OUT_DIR
Output directory for generated API clients.
{==string==}--APP_OUT_DIR=./src/api_client/
--APP_TYPE_STYLE
Sets the type style for generated DTOs. Can be 'Class' or 'Interface'.
{==string==}--APP_TYPE_STYLE=Interface
--APP_BUILD_DIR
Directory where TypeScript files will be compiled.
{==string==}--APP_BUILD_DIR=lib
(default is "dist")--SKIP_BUILD
Skip build step.
{==boolean==}--SKIP_BUILD=true
--VERBOSE
Enable verbose logging.
{==boolean==}--VERBOSE=true
!!! note For the
--APP_TYPE_STYLE
parameter, use exactly"Class"
or"Interface"
(case-sensitive). Any other value will cause an error.!!! tip Use
--APP_TYPE_STYLE=Interface
for better TypeScript integration and smaller bundle sizes. Use--APP_TYPE_STYLE=Class
when you need runtime type checking or class-specific features. -
Configure Platform URL to ensure your project can access the platform's API configurations. Add the platform URL to your project's .env file:
APP_PLATFORM_URL=https://vcmp-dev.govirto.com/
!!! note Alternatively, you can specify the Platform URL as a command option in the previous step when running the
"generate-api-client"
command. -
Generate the API clients using the following command:
yarn generate-api-client
This command generates the required API clients for your custom application. Now you can effortlessly access the VC Platform API from your custom application using the generated API client.
The generator now intelligently merges configuration files to preserve your custom settings. When you update an existing API client:
- Custom package.json fields like name, version, description, keywords, author and license are preserved
- Custom tsconfig.json settings are maintained
- Exports are intelligently updated to preserve existing paths
API client now includes metadata to track the generation:
{
"apiClientGenerator": {
"version": "1.1.0",
"generatedAt": "2025-04-01T12:30:45.123Z"
}
}
The generator handles multiple API clients effectively:
- Creates standardized exports with both short names (
./{moduleName}
) and full names (./virtocommerce.{moduleName}
) - Prevents duplicate module exports by intelligently merging with existing ones
- Automatically removes
module
andtypes
fields that conflict with multiple exports - Works properly with incremental generation (can add new APIs without breaking existing ones)
The generator now intelligently handles root exports based on the number of API modules:
-
Single API Module: When only one API module is generated, it automatically becomes the root export (
.
) andmodule
/types
fields are maintained -
Multiple API Modules: When multiple API modules are generated, only subpath exports are used (e.g.,
./moduleA
,./moduleB
) - Preserving Preferences: If a root export already exists, it will be preserved as long as it points to one of the generated modules
This enables both simple usage for single-API packages and proper subpath exporting for multi-API packages:
// Single API package (using root export)
import { MyClient } from '@myapp/api';
// Multi-API package (using subpath exports)
import { ClientA } from '@myapp/api/moduleA';
import { ClientB } from '@myapp/api/moduleB';
Target directories are automatically created if they don't exist.
Enable detailed logging to troubleshoot generation issues:
yarn generate-api-client --VERBOSE=true
You can specify a custom build directory where TypeScript files will be compiled:
yarn generate-api-client --APP_BUILD_DIR=lib
By default, the build directory is "dist".
Better error handling and reporting make it easier to diagnose issues during client generation.
- Configuration Preservation: Fixed issue where package.json and tsconfig.json user settings were being overwritten
- Export Path Management: Improved export path handling to prevent incorrect paths with duplicated prefixes
- Path Normalization: Added better path normalization to handle edge cases correctly
- Export Deduplication: Implemented smarter export merging to prevent duplicate exports with different path formats
- Build Directory Support: Added proper support for custom build directories via APP_BUILD_DIR parameter
- Declaration Files Location: Fixed issue with TypeScript declaration files location to match the build directory
- Error Handling: Improved JSON parsing error handling with better fallback strategies
- Root Export Handling: Fixed issue with root exports being ignored or improperly handled
- Intelligent Config Merging: Complete rewrite of configuration merging logic to better preserve user settings
- Export Path Standardization: New system for standardizing export paths to improve consistency
- Path Validation: Added strict validation of export paths to prevent invalid configurations
- Improved Logging: Added more detailed logging for better debugging
- Extended User Fields Preservation: Expanded the list of user-defined fields that are preserved during updates
- Better Directory Management: Improved directory creation and validation process
- Smart Single/Multi API Detection: Automatically detects single API scenarios and creates appropriate root exports
- Module/Types Field Handling: Preserves module and types fields for single API packages while removing them for multi-API packages
If you encounter issues during API client generation:
- Enable verbose logging with
--VERBOSE=true
- Ensure target directories have proper permissions
- Check your connectivity to the platform URL
- Verify that the specified platform modules exist
- If you encounter JSON parsing errors in tsconfig.json or package.json, try using the
--VERBOSE=true
flag to see detailed error messages - Check for duplicate exports in your package.json which might cause conflicts
- If you manually modified exports in package.json, ensure they follow the correct format
If you see an error like:
Error converting value "$(APP_TYPE_STYLE)" to type 'NJsonSchema.CodeGeneration.TypeScript.TypeScriptTypeStyle'
This means the APP_TYPE_STYLE
parameter was not properly validated or passed to NSwag:
Solution:
- Ensure you're using exactly
"Class"
or"Interface"
(case-sensitive) - Check that you're passing the parameter correctly:
--APP_TYPE_STYLE=Interface
- Enable verbose logging to see what value is being passed:
--VERBOSE=true
Example of correct usage:
yarn generate-api-client --APP_TYPE_STYLE=Interface --VERBOSE=true
If NSwag fails with exit code, check:
- .NET Core 6.0 or later is installed
- The platform URL is accessible
- The specified modules exist on the platform
- Enable verbose logging to see the full error output