APIOps for one APIM serving as multiple environments

[htwashere]

Question

Hello, I am trying to see if the apiops-cli could be used in this scenario: we use one APIM to serve multiple environments (e.g. dev/test). I plan to create the dev API initially by importing the swagger spec. Now in APIM, the api-id is registered with the imported name (e.g. call it my-dev-api). I want to migrate to a test version within the same APIM. I can use your override configuration yaml to change all the keys I need to. However, I cannot use the same name as the cli apiops publish will just do a PUT to the same API. Am I correct and is there a way to work around this?

Context

No response

[htwashere]

I just found this logged feature request, it looks to be the same as my question: #132

[github-actions]

⚠️ Stale issue notice — This issue has had no activity for 30 day(s).

It will be automatically closed after 60 days of inactivity.

To keep this issue open:

• Leave a comment describing the current status, or
• Remove the stale label.

This notice was posted automatically by the stale issue workflow.

[azaslonov]

Hi Henry,

Yes, your understanding is correct for the currently released version. The
ame in an override entry is used to match the existing artifact, and the override changes payload properties only. The API resource ID used for the PUT still comes from the artifact, so publishing the same artifact set to the same APIM instance targets the same API. Overriding displayName, path, or serviceUrl does not create a second API with a different resource ID.

You also found the right feature request: #132 tracks first-class support for multiple environments in one shared APIM instance. The implementation is in progress in #227. It adds an environment block with
amePrefix/
ameSuffix and �piPathPrefix, rewrites cross-resource references, and scopes --delete-unmatched to the selected environment namespace. That configuration is not available in a released version yet.

The only workaround today is to maintain a separately transformed artifact tree for each environment, renaming the API IDs and every affected cross-resource reference before publishing. This is manual and error-prone, especially for policies, named values, backends, products, revisions, and --delete-unmatched, so we do not currently recommend it as a general shared-APIM workflow. Separate APIM instances remain the supported approach until #227 is merged and released.

We will update #132 when the feature is available. Thanks for confirming the use case.