[FEATURE REQ] Workspaces Support

I must admit I don't know too much about them but I wonder what effect it will it have on this toolkit and whether there are changes needed within a roadmap to support them?

Currently workspaces are not supported by apiops as it's still in preview. Once Workspaces is out of preview it will be part of apiops. We can't promise any timeline but rest assured it will come down the line. In the meantime if you have ideas on how you feel the best implementation would look like we would love to hear your opinion as we are still going through the planning phase.

I actually don't see it as being too dissimilar, essentially we will of course want to extract and create workspaces within an instance and then for each workspace pretty much do what we do now i.e. extract products and api's but now will be scoped to a workspace rather than an instance

And would you rather see all the workspaces artifacts extracted to the same repository or would you rather use multiple repositories?

Excellent question - I didn't think of that but I guess keeping in spirit of supporting separate teams would mean having sperate repositories, one for the root and then additional ones for each workspace - that way it's much easier to isolate code and manage permissions on a granular level

Thanks for the feedback. And please keep using this thread if you have any other ideas as we are actively planning for this feature.

Seems to me like the work-space level resources (names values, backends, policy fragments) and workspace-scoped policies are the main value that workspaces could add to APIOps.

Apis as well. But remember there are global level artifacts and other that are unique to the workspace. Also workspaces will be optional so the tool has to adapt to that as well. Once we figure out all the details we will share back the details here and update the docs.

Hi!
Do you have any news about plans to support APIM workspaces?
We use APIOps extensively and very interested in this functionality.
Thank you!

It's in the workings, but as an open source project, we cannot promise any timelines. I suggest that you subscribe to the release notifications on the GitHub repo to be notified when we release the support for workspaces.

Also, please note that we always accept contributions from the community in case you are interested in implementing missing features.

cloudthingsDK

cloudthingsDK - currently, there are very few workspace-specific configurations.

If you run the extractor on an APIM instance with workspaces, workspace artifacts will be extracted. You can limit extraction to specific workspaces by using the workspaceNames configuration key.

workspaceNames:
  - workspace1
  - workspace2

Similarly, running the publisher against workspace artifacts will publish them to APIM. The current code doesn't have options to override workspace configuration.

In our next major release, we will support nested configuration, which will make workspace configuration better. You will be able to do things like:

In workspace1, only extract apiA. Do not extract 'workspace2'. In 'workspace3', extract all APIs.

workspaces:
  - workspace1:
      apis:
        - apiA
  - workspace3

Override the display name of apiB in workspace2 when publishing.

workspaces:
  - workspace2:
      apis:
        - apiB:
            properties:
              displayName: OVERRIDE-ME-HERE

guythetechie

guythetechie thanks for the info.
I have dev, test and prod environments. I understand i only have to limit which Workspaces i want to pull.
But can i still edit my configuration.prod.yaml file if I need different values for maybe backends and etc?

Like here: https://github.com/Azure/apiops/blob/main/configuration.prod.yaml

Yes, with a caveat. The YAML file only supports top-level resources, not nested ones.

You can currently override service-level backends. Using the example in your link, backend helloworldfromfunctionapp can be configured like this:

backends:
  - name: helloworldfromfuncapp
    properties:
      url: "https://helloworldfromprodfuncapp.azurewebsites.net/api"

If that backend lives in a workspace though, you can't override its properties in configuration. In our next major release, you'll be able to do it like this:

workspaces:
  - name: workspace1
    backends:
      - name: helloworldfromfuncapp
        properties:
          url: "https://helloworldfromprodfuncapp.azurewebsites.net/api"

Yes, with a caveat. The YAML file only supports top-level resources, not nested ones.

You can currently override service-level backends. Using the example in your link, backend helloworldfromfunctionapp can be configured like this:

backends:

name: helloworldfromfuncapp
properties:
url: "https://helloworldfromprodfuncapp.azurewebsites.net/api"
If that backend lives in a workspace though, you can't override its properties in configuration. In our next major release, you'll be able to do it like this:

workspaces:

name: workspace1
backends:

name: helloworldfromfuncapp
properties:
url: "https://helloworldfromprodfuncapp.azurewebsites.net/api"

Is there a timeline when the release is planned? We are planning to have an alignment on that release. And if I understand it right at the moment, all apis under a workspace will be extracted and cannot filter by api name.

and the option I have in the extractor file is the following:

workspaceNames:

myws01
myws02

but NOT like,

workspaceNames:

myws01
apis:
- api1

Is this assumption correct?

Thanks in advance.

guythetechie

guythetechie I need ask directly then.
If our need is different values for backend-services in test and prod, it means that currently Workspaces cannot be used with API-OPS.
Because I cannot change these values if deployed in Workspaces.

Is there a timeline for the new release because as Marione Espino (@spice67) is means I need to replan our current project.

@guythetechie I need ask directly then. If our need is different values for backend-services in test and prod, it means that currently Workspaces cannot be used with API-OPS. Because I cannot change these values if deployed in Workspaces.

Is there a timeline for the new release because as @spice67 is means I need to replan our current project.

I can confirm my own question and as well with the previous post that the extractor extracts the workspace level and cannot filter any (workspace) apis.

The artifacts are there but you can't override it .. yet.

Uses only:

workspaceNames:
- nameOfWorkspace

Marione Espino (@spice67)

Marione Espino (@spice67) and cloudthingsDK - you're both correct. Root level resources can be filtered and overridden. Workspace-level resources can't (yet).

As far a release date, I don't have an ETA. Here are a few updates:

Primary goals for v7 were nested configuration and restructuring the code to be more maintainable.
This v7 branch has nested configuration and the restructured code. It's missing API specifications, operation policies, and workspaces.
Our tests seem solid now, so we're adding missing resources back, in order of complexity. Currently working on API specifications (hopefully by done by end of week). Then we'll tackle workspaces (another week or so). Finally, API operation policies (much simpler than the others).

Please note that this is an open-source project, and life + day jobs take priority. The rough timelines above are very much subject to change, depending on what else we have going on. If this feature is a blocker for your project, and you need firmer commitments, I would advise you not to take a dependency on ApiOps.

guythetechie

@spice67 and @cloudthingsDK - you're both correct. Root level resources can be filtered and overridden. Workspace-level resources can't (yet).

As far a release date, I don't have an ETA. Here are a few updates:

Primary goals for v7 were nested configuration and restructuring the code to be more maintainable.

This v7 branch has nested configuration and the restructured code. It's missing API specifications, operation policies, and workspaces.

Our tests seem solid now, so we're adding missing resources back, in order of complexity. Currently working on API specifications (hopefully by done by end of week). Then we'll tackle workspaces (another week or so). Finally, API operation policies (much simpler than the others).

Please note that this is an open-source project, and life + day jobs take priority. The rough timelines above are very much subject to change, depending on what else we have going on. If this feature is a blocker for your project, and you need firmer commitments, I would advise you not to take a dependency on ApiOps.

Hi guythetechie,

I just want to emphasize how you guys do a good job on this. Like any other projects, there always a dependency on some tools when one way or another.

Just want to know a sort of a time line so we can adjust/plan accordingly with approximation of course.

Once again great work and keep up the good job which gives a lot to the community!

BR
/spice

Marione Espino (@spice67)

@spice67 and @cloudthingsDK - you're both correct. Root level resources can be filtered and overridden. Workspace-level resources can't (yet).
As far a release date, I don't have an ETA. Here are a few updates:

Primary goals for v7 were nested configuration and restructuring the code to be more maintainable.

This v7 branch has nested configuration and the restructured code. It's missing API specifications, operation policies, and workspaces.

Our tests seem solid now, so we're adding missing resources back, in order of complexity. Currently working on API specifications (hopefully by done by end of week). Then we'll tackle workspaces (another week or so). Finally, API operation policies (much simpler than the others).

Please note that this is an open-source project, and life + day jobs take priority. The rough timelines above are very much subject to change, depending on what else we have going on. If this feature is a blocker for your project, and you need firmer commitments, I would advise you not to take a dependency on ApiOps.

Hi @guythetechie,

I just want to emphasize how you guys do a good job on this. Like any other projects, there always a dependency on some tools when one way or another.

Just want to know a sort of a time line so we can adjust/plan accordingly with approximation of course.

Once again great work and keep up the good job which gives a lot to the community!

BR /spice

Thank you for the kind comment, Marione Espino (@spice67) . Very much appreciated!

I apologize for posting this question here. Need some clarification about workspace functionality. Our APIM instance is deployed in Internal mode behind an Application Gateway with a custom domain. When I publish APIs inside a workspace, the Developer Portal displays the workspace gateway URL as the Base URL, and calls fail with a 503 Service Unavailable error.

I also noticed that custom domain configuration is not allowed for the workspace API gateway.

Has anyone encountered this issue or can suggest a workaround to make the Developer Portal use the custom domain for workspace APIs?

Marione Espino (@spice67)

Marione Espino (@spice67) - the v7 branch should now have full workspace support. I haven't done much testing yet, so expect bugs. That said, feel free to start playing around with it.

I apologize for posting this question here. Need some clarification about workspace functionality. Our APIM instance is deployed in Internal mode behind an Application Gateway with a custom domain. When I publish APIs inside a workspace, the Developer Portal displays the workspace gateway URL as the Base URL, and calls fail with a 503 Service Unavailable error.

I also noticed that custom domain configuration is not allowed for the workspace API gateway.

Has anyone encountered this issue or can suggest a workaround to make the Developer Portal use the custom domain for workspace APIs?

Sorry, no idea. I would suggest raising a support ticket from the Azure portal.

guythetechie

@spice67 - the v7 branch should now have full workspace support. I haven't done much testing yet, so expect bugs. That said, feel free to start playing around with it.

Hi, guythetechie, thanks for the update and info. I just seen this now... a lot of things on customer side for closing the year. :) And customer's still evaluating on their end (still on v6.0.2-alpha.1.0.3) so it's good that this came out now. It would be nice to play around during the intermediate days under the holiday season. :-D. Keep up the good work!

Navigation Menu

Repository navigation

[FEATURE REQ] Workspaces Support #274

21 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE REQ] Workspaces Support #274

Description

Activity

waelkdouh commented on Apr 18, 2023

dannythomas13 commented on Apr 18, 2023

waelkdouh commented on Apr 18, 2023

dannythomas13 commented on Apr 18, 2023

waelkdouh commented on Apr 18, 2023

shawnmurtagh commented on Apr 26, 2023

waelkdouh commented on Apr 26, 2023

KanatAbishJTI commented on Feb 13, 2024

waelkdouh commented on Feb 13, 2024

21 remaining items

guythetechie commented on Sep 30, 2025

cloudthingsDK commented on Oct 1, 2025

guythetechie commented on Oct 1, 2025

spice67 commented on Oct 2, 2025

cloudthingsDK commented on Oct 3, 2025

spice67 commented on Oct 4, 2025

guythetechie commented on Oct 6, 2025

spice67 commented on Oct 7, 2025

guythetechie commented on Oct 8, 2025

sangal15 commented on Oct 15, 2025

guythetechie commented on Nov 14, 2025

guythetechie commented on Nov 14, 2025

spice67 commented on Dec 11, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions