Send Docs Feedback

Apigee Edge organization structure

Before you start building APIs with Apigee Edge, you should be familiar with the organizational model of Edge. This model defines how your APIs, API products, apps, and app developers are all related within Edge.

The following image shows the major components of the Edge organizational model:

For example, an organization can contain one or more users and one or more API products, while an app uses a single key to access one or more API products.

This model does not show all of the features of Apigee Edge. If you take advantage of monetization or API BaaS (formerly App Services), then the model would have additional components. For more information, see The basics of monetization and API BaaS.

When you create an Edge account, Edge automatically creates an organization for you. Once created, you can add users to your organization, create API proxies and API products, and register developers and apps. You can later add additional organizations as necessary.

For Cloud customers, you must contact Apigee Support to delete an organization. For Edge for Private Cloud customers, the system administrator can delete an organization. See the Edge Operations Guide, available on the Apigee ftp site:, for more information.   

The name of the organization is your Edge username. The organization name becomes part of the URL to your API proxies and part of the URL when making a request to the Edge management API. For example, a typical URL used to access an API proxy has the form:



  • {org-name} is the name of your organization.
  • {env} is the deployment environment of the API proxy, which is either test or prod.

For example:

The following table describes the components of the organizational model in more detail:

Component Description


Every Apigee account maps to one or more organizations on Apigee Edge. The organization contains a representation of all components including API proxies, API products, API packages, apps, and developers.

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.

Free Edge accounts are limited to creating only a single organization—though a free account holder can be a member of multiple existing organizations.


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 Edge 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 Edge here:

API proxy

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.

Edge collects data for analytics on API proxies.

API product

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.

Edge 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 Edge management UI, create a developer portal to register them through a website, or define your own registration mechanism by using the Edge management API. 

A developer is not required to have an account on Edge, and most developers will not need to know anything about Edge. If the developer does have an account on Edge, it is typically as a user in a different organization, or to use the Edge API Services.

In addition to your APIs, app developers also have access to Edge Advanced API Services, which provides a flexible NoSQL data store and features such as social graphs, geolocation, user management, push notifications, performance monitoring, and more.

Because your API developers are registered in your organization, you can use Edge to monitor and collect analytic information on developers and their use of your APIs.


Developers create one or more client apps that consume your APIs.

Developers must register their apps with your organization. An App in Edge 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 Edge 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. Edge 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 Edge).

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.


Help or comments?