In this article, we explore what a multi-org setup in one developer portal means in the context of Google Cloud’s Apigee API management platform, the scenarios where it is most useful, and how it supports flexible API management across environments, business units, and regions. We also share how we use this setup to support use cases such as separating APIs across multiple gateways (including Azure), and how it further helps us simplify developer onboarding and streamline the Apigee migration process.
What is multi-org?
The need for supporting multiple organizations typically emerges in conversations with our clients who are also Apigee customers. In this context, "org" refers to an "organization" as a single Apigee instance, where based on different aspects, APIs are managed separately. For this reason, there are more than one API gateway instances, and it usually has three scenarios:
It is important to clarify that the term 'environment' in this article does not refer to the Apigee-specific construct of the same terminology within an organization or Apigee instance. While Apigee environments (as defined in the following documentation) are useful for managing API proxies, they do not provide the same level of access control or separation as treating an entire organization or instance as a distinct environment. In this context, we use the term 'environment' to mean a fully separate organizational unit, with stronger boundaries for governance, compliance, and security.
How does multi-org work in practice?
We usually see three use cases:
- Environment separation: data stored at one gateway instance behaves as a separate data store. Access is strictly managed. For example, there can be an organization or gateway instance (for devs and sandbox) and User Acceptance Testing (where one can find APIs that are closer to production and only a limited number of employees have access to that instance). This use-case is common in the banking sector and government-affiliated institutions.
- Business unit separation: there are organisational (company-level) constraints, which are usually competing business units. In such cases, the competing branches cannot be in the same database. This also means that each API product is specific to each org and keys are provisioned per org.
- Data regions: companies have business interests in different regions (for example in the EU and Asia), where regulations vary and data cannot leave the country. These scenarios call for distinct business processes.
While environments and business units serve distinct purposes, they are often easy to confuse. A business unit can have its own dedicated environments. The distinction between the two can be illustrated as follows:
Across different multi-org setups, our approach enables a single developer portal, as long as data security considerations allow for one developer platform instance accessing data from multiple Apigee instances. This way, developers only need to register once, and they will automatically be directed to the right organization (org) context, ensuring seamless access to the APIs they need.
Useful solution: different gateways, Google Cloud’s Apigee migration, and API key request
Beyond the use cases outlined above, the same principles can also support scenarios where organizations use Google Cloud’s Apigee alongside another API management platform with a gateway at its core such as Microsoft Azure. In such multi-gateway setups, terminology and processes may differ (for example, whether access requires an app or a subscription), but Pronovix's developer portal approach can integrate with multiple gateways (for example Google Apigee, Microsoft Azure, etc.) and make API key requests seamless for users.
In Pronovix developer portals, we use Federated API Management to balance centralized API governance with the flexibility of decentralized API deployment. This model allows the different teams to manage their preferred gateways while maintaining consistent oversight, documentation, and user experience across the enterprise. We also support seamless integration with non-API-based systems, such as data-sharing platforms (like SAP), and they provide access to AI agents and AI models through Drupal AI and Google Cloud integrations.
If you want to know more about integrating diverse API gateways into one seamless developer experience, read the Multiple API Gateways On One Developer Portal article.
Multi-org setup in one developer portal becomes especially critical during Apigee migrations (for example, when transitioning from Edge to X) where two organizations (orgs) need continued access to applications throughout the migration process.
Based on your requirements, Pronovix can enable different rulesets for creating API keys. In the context of Figure 1, these can be the possible use cases for separation of access provisioning:
- Environment: the lower level environment organization can have an immediate key request, while on the production one, users need to send a custom request.
- Business unit: separate business units (see Figure 2) can have several API key access workflows, and these business units will only see requests belonging to those under their purview.
- Region: based on the regulations, they have to have different workflows and terms of use.
We are always keen on building a solution that fits your use case.
Let’s discuss your needs.
Conclusion
As organizations grow in complexity, whether through regional expansion, internal business structuring, or increasing security and compliance demands, the need for more advanced API management strategies becomes crucial. One such strategy is multi-org setup in one developer portal, a common requirement among Google Cloud Apigee clients that need to maintain separation and control across different parts of their infrastructure.
If your organization faces challenges around API management, regional regulations, or internal access control, understanding multi-org is essential. We warmly invite you to contact us, and our experts will offer the best possible solution catering to your needs.
All Pronovix publications are the fruit of a team effort, enabled by the research and collective knowledge of the entire Pronovix team. Our ideas and experiences are greatly shaped by our clients and the communities we participate in.
