We are currently using IBM API Connect and have deployed multiple User-Defined Policies (UDP) to support shared integration and processing flows across the system.
During actual system operation, we encountered a concern related to the UDP update mechanism and would like to understand how other teams are handling this in enterprise environments.
At present, when we need to modify the logic of an existing UDP on API Manager, we are unable to overwrite the current version of the policy. Specifically, when attempting to re-upload the following policy:
Example:
Existing UDP:
* name: `ExceptionHandling`
* version: `1.0.0`
Uploading a new ZIP/YAML with the same:
* name: `ExceptionHandling`
* version: `1.0.0`
the system returns the following error:
"The Policy cannot be created with name 'health-check-generator' and version '2.0.0'. Another resource of type policy already exists with the same name and version."
Based on our investigation, we understand that IBM API Connect manages UDPs as immutable artifacts, meaning each `(policy name + version)` combination is unique and cannot be overwritten directly.
However, in an enterprise environment where a large number of APIs are using the same UDP, this behavior introduces several operational challenges:
* Any logic change requires creating a new UDP version.
* All APIs using the old policy version must then be manually updated to reference the new version.
* This process requires significant operational effort and introduces deployment risks in large-scale environments.
* Managing multiple UDP versions also increases complexity in CI/CD pipelines and lifecycle management.
We would appreciate hearing how other teams are handling the following topics:
1. Is there any supported mechanism or workaround to centrally update an existing UDP version without modifying all APIs?
2. If creating a new version is mandatory by design:
* how are teams managing UDP lifecycle at scale?
* are there any recommended DevOps/GitOps approaches?
* does anyone use scripts, APIs, or automation to bulk-update policy versions across APIs?
3. For policies already used by many APIs:
* what upgrade strategy is typically recommended?
* how do teams minimize operational impact and version sprawl?
Would appreciate hearing real-world experiences, best practices, or tooling recommendations from teams operating IBM API Connect at scale.
Thank you for your support.
Best regards,