组织是 Apigee 中的顶层容器。Apigee 组织包含您的所有 API 代理及相关资源。虽然本主题的其余部分更加深入地介绍了组织，但是下面列出了一些有用的要点：
Apigee 组织与 Google Cloud 组织不同，是 Google Cloud 组织的子级。为 Apigee X 或 Apigee Hybrid 创建组织时，该组织只映射到一个 Google Cloud 项目，并且 Apigee 组织和 Google Cloud 项目共用一个名称。并非所有 Google Cloud 项目都有关联的 Apigee 组织。
环境组是一组具有一个或多个主机名的环境。主机名是用于调用部署到环境组中任何环境的 API 代理的网址的一部分。
API 代理
API 代理是传入请求和后端服务之间的接口。代理实体包含 Apigee 在处理来自客户端的请求和来自后端的响应时执行的说明和政策。
API 产品
用于发布 API 的实体。API 产品会被发布到开发者门户，以供外部开发者使用。API 产品提供了用于访问一个或多个已发布 API 的接口。接口（可通过 OpenAPI 规范描述）可能包含由一个或多个 API 代理处理的一个或多个 API 请求的组合。
组织中的用户可以创建 API 产品。 执行此操作时，它们可以将任意元数据附加到每个 API 产品。一种常用的元数据类型可以定义服务计划，从而指定 API 调用访问限制、规定安全要求、允许监控和分析，以及提供其他功能。
Apigee 会收集有关 API 产品的分析的数据。
API 提供方
创建和管理 API 代理和产品的个人或实体。客户端应用开发者会访问这些发布的 API。
应用开发者
组织包含一个或多个开发者，他们构建使用您的组织定义的 API（发布为 API 产品）的应用。开发者使用 API，但不能创建 API，也不能在组织中执行任何其他操作。
开发者可以是公司内部的开发者，可以是合作伙伴，也可以是免费或付费访问 API 的外部开发者。您可以将开发者视为使用您的 API 的客户。
您必须先在组织中注册开发者，然后他们才能注册应用并接收允许访问 API 的 API 密钥或其他客户端凭据。作为 API 提供方，您自行决定如何在组织中添加、更新或移除开发者。您可以通过界面手动添加开发者，创建开发者门户以通过网站注册开发者，或者使用 Apigee API 定义并实现您自己的注册机制。
Apigee 应用（或应用）
Apigee 开发者创建一个或多个使用您的 API 的客户端应用。
如果开发者创建的客户端应用调用的 API 需要检查凭据（例如 API 密钥或 OAuth 令牌），则必须先向组织创建应用注册。应用注册向开发者提供 API 密钥、密钥/密码对，或者客户端应用在调用 API 时必须使用的其他凭据。
由于组织中的所有应用均已注册，因此您可以使用 Apigee 来监控和收集有关该应用及其使用您的 API 情况的分析信息。
未显示的其他 Apigee 组件包括 API 密钥和 OAuth 令牌。
Apigee 支持不同类型的身份验证，例如简单的 API 密钥、二足式 OAuth、三足式 OAuth 等等。
如果 API 提供方指定 API 密钥验证作为授权机制，则客户端应用必须在每个 API 请求中传递 API 密钥。如果该密钥有效，Apigee 会允许请求。或者，如果 API 提供方将 OAuth 令牌验证指定为授权机制，则客户端应用必须先获取 OAuth 令牌，然后在每个 API 请求中传递该令牌。如果该令牌有效，Apigee 会允许请求。还可能有其他自定义授权机制。
作为 API 提供商，您必须定义开发者注册其应用的方法。每个应用注册将会有一个或多个密钥或凭据与之关联。如果您允许开发者通过开发者门户注册自己的应用，则开发者可以通过便捷的自助体验来检索访问您的 API 所需的密钥或凭据。
在注册应用时，开发者可以选择访问单个 API 产品或多个 API 产品。开发者的应用使用相同的密钥/凭据访问与该应用关联的所有 API 产品。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-05。"],[[["\u003cp\u003eApigee organizations are top-level containers for API proxies and resources, distinct from Google Cloud organizations but mapped to a single Google Cloud project with a shared name.\u003c/p\u003e\n"],["\u003cp\u003eThere are two types of Apigee organizations: paid (production) organizations with full scalability and evaluation (eval) organizations, which are temporary and time-limited.\u003c/p\u003e\n"],["\u003cp\u003eAn Apigee organization's structure contains components such as environments, API proxies, API products, API providers, app developers, and apps, all managed within the organization's framework.\u003c/p\u003e\n"],["\u003cp\u003eApigee offers subscription and pay-as-you-go pricing models, with entitlements and billing based on environments, API calls, and proxy deployments, and also allowing users to be members of multiple organizations.\u003c/p\u003e\n"],["\u003cp\u003eApigee users within an organization can have various roles, from administrators to API creators, and end-users access APIs through apps built by Apigee developers.\u003c/p\u003e\n"]]],[],null,["# Understanding organizations\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nAn organization is the top-level container in Apigee. The Apigee organization\ncontains all your API proxies and related resources. While the rest of this topic goes into\nmore depth about organizations, here are a few practical points:\n\n- An Apigee organization is distinct from and subsidiary to a Google Cloud organization. When you create an organization for Apigee X or Apigee hybrid, it maps to exactly one Google Cloud *project*, and the Apigee organization and Google Cloud project share a name. Not all Google Cloud projects have an associated Apigee organization.\n- Where the Apigee documentation uses the term \"organization,\" it specifically refers to an Apigee organization. The Apigee documentation uses the phrase \"Google Cloud organization\" to refer to the alternative.\n- Once created, you cannot rename an Apigee organization.\n- Your Apigee organization name is shown as the project in the URL for the Apigee section of [the Google Cloud console.](https://console.cloud.google.com/apigee/overview) For example: \n\n ```\n https://console.cloud.google.com/apigee/overview?project=ORG_ID\n ```\n- When you invoke REST calls to the Apigee API, the organization identifier is a required part of the path. For example, the following `curl` request returns a list of all API proxies in an organization using the [organizations API](/apigee/docs/reference/apis/apigee/rest/v1/organizations): \n\n ```\n curl https://apigee.googleapis.com/v1/organizations/ORG_ID/apis\n ```\n- While you may have created only one organization, you can be authorized in other organizations as a user or administrator with specific permissions. In the cloud console, you can switch to a different organization as described in [Switching between\n your organizations](/apigee/docs/api-platform/get-started/switch-org).\n\n**Note:** This video was recorded with a previous version of the Apigee UI; however, the concepts are still valid. \n**Video:** Watch a short video to learn how organizations support a\nmulti-tenancy architecture for API management. \n\nOrganization types\n------------------\n\nThere are two types of organizations:\n\n- **Paid:** A permanent organization with full scalability. Also known as a\n *production* organization. Paid organizations include those created as part of a Subscription or a Pay-as-you-go\n Apigee pricing model.\n\n- **Evaluation:** A temporary, self-service organization for testing\n Apigee. Sometimes referred to as *eval orgs*, these organizations are time-limited and\n lack the scalability and flexibility of production organizations.\n\n\nSee also [Compare eval and paid organizations](/apigee/docs/api-platform/get-started/compare-paid-eval).\n\n#### Evaluation organization lifespan\n\nEvaluation organizations have a limited lifespan:\n\n1. **Day 0:** Create the evaluation organization.\n2. **Day 30:** Google sends you an email notification warning of the upcoming expiration.\n3. **Day 60:** Google deletes the evaluation organization.\n\nApigee Organizations within the Google Cloud hierarchy\n------------------------------------------------------\n\nThe following diagram shows the relationship between Apigee organizations and environments,\nand Google Cloud projects and folders.\n\nComponents within an organization\n---------------------------------\n\nThe following image shows the major components of the Apigee organizational model.\nThis model defines how your APIs, API products, apps, and app developers are all related within\nApigee.\n\nThis model does not show all of the features of Apigee, but it is meant to show you that the\norganization is the root of a deployment.\n\nThe following table describes the components of the organizational model in more detail:\n\nAdditional components of Apigee that are not shown are the API keys and OAuth tokens.\n\nApigee supports different types of authentication, such as a simple API key,\ntwo-legged OAuth, three-legged OAuth, and others.\n\nIf the API provider specifies API key verification as the authorization mechanism, the\nclient application must pass an API key with every request to your APIs. If\nthat key is valid, Apigee allows the request. Alternatively, if the API\nprovider specifies OAuth token verification as the authorization mechanism, the client\napplication must first obtain an OAuth token, and then pass that token with\nevery request to your APIs. If that token is valid, Apigee allows the\nrequest. Other custom authorization schemes are possible.\n\nAs an API provider, you must define a way for developers to register their apps. Each\napp registration will have one or more keys or credentials associated to it. If you\nallow developers to register their own applications via a developer portal, the developer\ncan retrieve the key or credential required to access your APIs, via a convenient,\nself-service experience.\n\nAt the time of app registration, developers can choose to access a single API\nproduct or multiple API products. A developer's app uses the same key/credential to access\nall API products associated with the app.\n\nAt any time, you can revoke the key so that the developer's app no longer has access\nto your APIs (even though the registered representation of the developer's app still\nexists in your organization). Or, you can revoke a developer, in which case all of the credentials\nfor any apps registered for that developer become inoperable. Revocation is reversible.\nAt the time Apigee creates the app credential,\nyou can specify an expiry so that the\ndeveloper must obtain a new key or credential after a specific time.\n\nApigee users\n------------\n\nApigee users make up the organization's API team,\nwhich can include people such as administrators, API proxy and API product creators,\nor users monitoring analytics and other statistics. End-users are people who use the\napps that Apigee developers build. In most cases, this documentation uses the term \"user\"\nto refer to an Apigee user.\n\nAdministrators can add users to an organization.\n\nDifferent users can have different roles and access privileges. For example, define\nsome users as Organization Administrators and Operations Administrators with privileges\nto modify the organization and its components, and define other users with permissions to\ncreate API proxies and API products, but without the privileges to modify other\nusers.\n\nUsers can be members of multiple organizations. For example, your company might define\nmultiple organizations on Apigee to support different developer communities, even\nthough internally, the same people build all of the API proxies and API products and are\ntherefore members of all of your organizations.\n\nYou don't have to create an Apigee organization to be a user. An administrator\ncan add you to an existing organization.\n\nIn the Google Cloud console, go to the Apigee page.\n\n[Go to Apigee](https://console.cloud.google.com//apigee)\n\n\u003cbr /\u003e\n\nEntitlements and billing\n------------------------\n\nWhether the paid organization uses a **Subscription** or **Pay-as-you-go**\npricing model, the items that are metered for billing purposes are:\nenvironments, API calls, and proxy deployments.\n\nSubscription plans allow you to pre-pay for entitlements, in exchange for significant\ndiscounts. Subscription plans make sense at higher consumption volumes - where there are larger\nnumbers of environments, a high volume of API calls, or a large number of API proxies under\nmanagement by Apigee. Under the Pay-as-you-go model, you pay only for the resources you use, but\nyou do not enjoy volume discounts.\n\n### Subscription entitlements\n\nFor more details, see [Subscription entitlements](/apigee/docs/api-platform/reference/subscription-entitlements).\n\n\n### Pay-as-you-go entitlements\n\nFor more details, see [Pay-as-you-go entitlements](/apigee/docs/api-platform/reference/pay-as-you-go-entitlements)."]]
