An organization is the top-level container in Apigee. It contains all your API proxies and related resources. While the rest of this topic goes into more depth about organizations, here are a few practical points:
- Once created, you cannot rename an organization.
- Your organization name is in the URL of the Apigee UI. For example:
- When you make calls with the Apigee API, the organization is a required part of the path in
most calls. For example, the following
curlrequest returns a list of all API proxies in an organization using the organizations API:
- While you may have created only one organization, you can belong to other organizations as a user or administrator with specific permissions. You can switch to a different organization as described in Switching between your organizations.
- An Apigee organization is not the same as a Google Cloud organization. Where the possibility of ambiguity exists, this document specifies that the "organization" is an Apigee organization.
Video: Watch a short video to learn how organizations support a multi-tenancy architecture for API management.
There are two types of organizations:
Production: A permanent organization with full scalability. Creating a production organization requires a contract with Apigee.
Apigee grants you entitlements per your contract so that you can create this organization, as described in Overview and prerequisites.
Evaluation: A temporary, self-service organization for testing Apigee. Also known as eval orgs, these organizations are time-limited and lack the scalability and flexibility of production organizations.
You create, or provision, your own eval org without any entitlements, as described in Creating an evaluation organization.
Eval org lifespan
Eval orgs have a limited lifespan:
- Day 0: Create the eval org.
- Day 30: Google sends you an email notification warning of the upcoming eval expiration.
- Day 60: Google deletes the eval org.
Eval vs prod comparison
Both production and evaluation organizations have full functionality; the differences between them lay mostly in scaling and infrastructure allowances, as the following table shows:
|Lifespan||Based on contract||60 days||For an eval org, you will get a notification after 30 days that its lifespan is limited. After 60 days, Google deletes the eval org. You cannot extend its lifespan.|
|Requires VPC peering?||Eval orgs require VPCX peering, whereas you can configure a production organization without one.|
|Proxy access||External or private/local access||Private/local access only||By default, API proxies can be accessed internally only: after deploying an API proxy to you runtime, you must create a new VM inside the network and then send a request from that VM. (Production orgs have a UI that lets you expose an external load balancer so that you can then make requests to the proxy from outside the runtime.)|
|Supported instances||Based on contract||1||The number of runtime instances.|
|Runtime fault tolerance||Regional||Zonal||
Runtimes in eval orgs run in a single zone only; if that zone goes down, then the eval org will be unavailable.
Runtimes for production orgs use regional clustering, which means that if a zone goes down, Apigee can re-route requests to the runtimes in other zones within the region.
For more information about regions and zones, see Regions and zones.
|Scalability and sizing||Production orgs have a maximum of 100 UDCA pods, 4 synchronizer pods, and 100 runtime pods per node in the cluster. Eval orgs are limited to 1 UDCA pod, 1 synchronizer pod, and 2 runtime pods per node.|
For additional information, see Apigee Pricing.
The following image shows the major components of the Apigee organizational model. This model defines how your APIs, API products, apps, and app developers are all related within Apigee.
This model does not show all of the features of Apigee, but it is meant to show you that the organization is the root of a deployment.
The following table describes the components of the organizational model in more detail:
Every Google Cloud account maps to one organization. The organization contains a representation of all environemtns, plus API proxies, API products, API packages, apps, and users.
Account holders are not limited to a single organization. Some account holders might define or be a member of multiple organizations that support different app developer communities.
|Environments and environment groups||A runtime execution context for the API proxies in an organization. For more information, see About environments and environment groups.|
Apigee User (or User)
Apigee users make up the organization's API team, which can include people such as administrators, API proxy and API product creators, or users monitoring analytics and other statistics. End-users are people who use the apps that Apigee developers build. In most cases, this documentation uses the term "user" to refer to an Apigee user.
Administrators can create more users.
Different users can have different roles and access privileges. For example, define some users as Organization Administrators and Operations Administrators with privileges to modify the organization and its components. Define other users with permissions to create API proxies and API products, but without the privileges to modify other users.
Users can be members of multiple organizations. For example, your company might define multiple organizations on Apigee to support different developer communities. Internally though, the same people build all of the API proxies and API products and are therefore members of all of your organizations.
You don't have to create an Apigee account—that is, create an Apigee organization—to be a user. An administrator can add you to an existing organization.
All users log in to Apigee here: Apigee UI.
An API proxy defines a mapping of a publicly available HTTP endpoint to a backend service. API proxies can also be configured to include security (such as OAuth), perform message transformation (such as XML to JSON), limit traffic to backend services, and perform other valuable operations on the request, the response, and with service callouts.
The users in an organization create one or more API proxies.
Google collects data for analytics on API proxies.
A bundle of API proxies combined with a service plan. That service plan can specify access limits on API proxies, provide security, allow monitoring and analytics, and provide additional features.
The users in an organization create API products.
Apigee collects data for analytics on API products.
The entity that creates and manages API proxies. Client app developers access API proxies.
An organization contains one or more developers who build the apps that consume the APIs (assembled into API products) defined by your organization. Developers consume APIs but cannot create APIs or perform any other actions in the organization.
Developers can be internal to your company, they can be partners, or they can be external developers who pay for access to your APIs. You might think of some developers as customers.
Developers must be registered in your organization before they can register an app and receive an API key to access your APIs. As an API provider, it is up to you to determine how to add, update, or remove developers in your organization. You can manually add them through the UI, create a developer portal to register them through a website, or define your own registration mechanism by using the Apigee API.
Apigee App (or App)
Apigee developers create one or more client apps that consume your APIs.
Developers must register their apps with your organization. An app is a representation of a developer's actual app that provides the developer with an API key to pass in with every request to your APIs.
Because all apps are registered in your organization, you can use Apigee to monitor and collect analytic information on the app and on its use of your APIs.