Introduction
Pre-requisites
- A webMethods.io Integration tenant.
- Administrator access to the webMethods.io Integration platform to execute APIs.
Audience
Use case
The client has developed assets on their development tenant. Their platform team aims to streamline and automate the deployment of these assets to higher environments by leveraging APIs.
Note: For all API invocation we need to use the API key, which needs to be generated from the tenant and this needs to be passed in headers.
Key name: X-INSTANCE-API-KEY
Value: Will get generated from the tenant
Step 1: Export Project Assets from Source Tenant
This API allows you to export all assets developed within a project. The export is provided as a downloadable file, and the response includes a link to the file. The link is valid for a limited period, with the validity duration specified in the response.
- Workflows
- Flow Services
- Custom Connectors
URL: https://<TenantName>/apis/v1/rest/projects/<projectID>/export
Step 2: Export Project Configurations from Source Tenant:
This API enables the export of project configurations, including connector settings, global variables, certificates, and other relevant
"source": "originawsdev1",
"project": "fl5a3a590ea461f56597c0a5",
"generatedOn": 1752490096890
"versionControlAccounts": [
"hostname": "github.ibm.com",
"username": "Vikash-Sharma5",
"displayName": "vikashIBMgithub",
"hostname": "dev.azure.com",
"username": "vikashSharma5",
"displayName": "vikasAzureRepo",
Step 3: Create project on target tenant (Optional):
This is an optional step to be executed if the project is not already available in the target tenant. The project can be created in the target tenant using the same project ID as the source tenant. Using the same project ID ensures that the ID references in the configurations and assets exported are automatically handled. Refer to the API details below.
"name": "LogisticsAssets",
"uid": "fla221ab7f8cdb8b22cf3ffm"
"name": "LogisticsAssets",
"uid": "fla221ab7f8cdb8b22cf3ffm",
"tenant_uid": "fl4c27abef2ef70d742812e3",
"created_at": "2025-07-14T11:53:36.815Z",
"updated_at": "2025-07-14T11:53:36.815Z"
- In case if we are creating the version control source project then also all workflow and flow services assets will still reside on internal git.
Step 4: Import configurations target tenant: This API facilitates the import of configurations into the target tenant. Importing configurations before importing assets ensures that all asset references are intact and ready for use during the asset import process.
Key Considerations Before Importing Configurations:
-
Environment-Specific Configuration Values:
-
- Modify environment-dependent values for configuration assets, such as global variable values, before importing them.
-
Individual Configuration APIs:
-
- While the export process includes all configurations, there are separate APIs available for each configuration type. You can use these individual APIs to update specific configuration values as needed.
-
- If your implementation involves certificates, it is recommended to use the Create API for certificates to generate them on the target tenant.
-
- If certificates are being created in a keystore or truststore, ensure that their names remain unique across all projects.
-
- Custom connectors, such as REST connectors, are treated as assets rather than configurations.
-
- If a custom connector is not used in any flow service, it will not be included in the export.
URL: https://<TenantName>/apis/v1/rest/projects/<ProjectID>/configurations
Step 5: Import Assets target tenant
This API imports the assets into the target tenant. The file that was exported in step 1 is to be sent as an input to this API.
Content-Type: multipart/form-data
X-INSTANCE-API-KEY : <value generated from tenant>
Project: zip export of project
new_project_name: <name of the project>
"status": "IMPORT_SUCCESS"
Step 6: [Optional] Validation Step End to End Testing target tenant: After the importing of assets, we should be able to execute the flow services and workflow on our target tenant.
- In this approach all the assets are not bundled as a single zip but here it will be more of cherry pick approach.
- For example, suppose if you have changed a single flow service and configurations related to it then to push those changes you need to explicitly invoke those API’s one after another.
Use case: Developer has modified the assets to implement some functionality.
- Created the new connection
So in this case we need invoke the API for each of them explicitly.
API: URL: https://<TenantName>/apis/v1/rest/projects/flows/<flowserviceName>/export
API: URL: https://<TenantName>/apis/v1/rest/projects/flow-import
Request Body: multipart type
Recipe: zip file for exported flow service asset
URL: <Tenant URL>/apis/v1/rest/projects/<ProjectID>/variables?type=projectVariable
URL: <Tenant URL>/apis/v1/rest/projects/<ProjectID>/variables?type=projectVariable
Note: All the types of variables can be handled using these API’s. We just need to provide the correct variable type like project variable, package variable
Create connection:
- To create the connection in the target tenant we require json body to pass as payload.
- Easy way to generate the Json body is to invoke the get connection API for your source tenant and then modify the same Json body to create the connection in target tenant.
Note : This is not mandatory, it just a way to get the payload ready quickly and efficiently.
URL: https://<TenantName>/apis/v1/rest/projects/<projectID>/configurations/connections
Now use the above response payload as base and modify it so that same can be passed as request payload for creating the connection.
API: https://<TenantName>/apis/v1/rest/projects/<projectID>/configurations/connections
"name": "ConnectionName",
"authenticationScheme": "credentials",
"uid": "uconn7a34853ce8d06f009c5c37454eb7ecb832bf04c5",
//Paste actual connection details
Note: We offer different types of connectors like node.js connectors, cloud stream connectors and adapters. In the above payload some of the values like (type, provider name, connection Type) will differ based on which type of connector we are planning to create
Request body: Multipart Type
Sample for multipart type
{"certificateType":"KEY_STORE","certificateConfig":{"name":"AnyName","description":"keystore desc","type":"JKS","provider":"SUN","password":" ReplacewithPassword ","projectName":"ReplacewithprojectID","keyAliases":[{"alias":"test","password":"ReplacewithPassword"}]}}
File: upload the jks file.
Note: Keystore and truststore name should be unique across the project.
- Approach 2 is recommended when developer is aware of what specific assets need to be updated or modified.
- As we need to update each asset explicitly by invoking the API’s, It is recommended to announce upgrade downtime for the target tenant till this activity completes.
- If we are updating any global variables and those global variables are getting used in connector account configuration. Them we need to disable and enable the account to get the new value come into effect at connector level.