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:
curl https://apigee.googleapis.com/v1/organizations/your_org_id/apis -u org_admin_email_address
- 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.|
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. See the section below for more on environments. For more information, see Environments and environment groups.|
Within an organization, where the person creating the account is automatically an administrator, you can create more users. Users make up the organization's API team, which can include people such as administrators, API proxy and API product creators, users monitoring analytics and other statistics, and any others.
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.
The users in an organization create one or more API proxies. 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.
Google collects data for analytics on API proxies.
The users in an organization create one or more API products, where an API product is a bundle of API proxies combined with a service plan. That service plan can set access limits on API proxies, provide security, allow monitoring and analytics, and provide additional features.
Apigee collects data for analytics on API products.
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.
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.
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.
API key/OAuth token
Depending on the authorization mechanism you define for your APIs, the app passes an API key along with every request to your APIs. If that key is valid, the request is allowed. Apigee supports different types of authentication, such as a simple API key, two-legged OAuth, three-legged OAuth, and others.
As an API provider, you must define a way for developers to register their apps. It is by registering their app that you return to the developer the key required to access your APIs.
At the time of app registration, the developer can choose to access a single API product or multiple API products. The developer's actual app uses the same key to access all API products associated with the app (the registered representation of the developer's app in Apigee).
At any time, you can revoke the key so that the developer's app no longer has access to your APIs (even though the registered representation of the developer's app still exists in your organization). Or, you can define a time limit on a key so that the developer must refresh the key after a specific time.