機構是 Apigee 中的頂層容器，Apigee 機構包含所有 API Proxy 和相關資源。本主題的其餘部分會深入探討機構，以下是一些實用要點：
Apigee 機構與 Google Cloud 機構不同，且隸屬於後者。為 Apigee X 或 Apigee Hybrid 建立機構時，該機構會對應至一個 Google Cloud 專案，且 Apigee 機構和 Google Cloud 專案會共用名稱。並非所有 Google Cloud 專案都有相關聯的 Apigee 機構。
環境群組是一組環境，包含一或多個主機名稱。主機名稱是網址的一部分，用於呼叫 API Proxy，這些 Proxy 會部署至環境群組中的任何環境。
API Proxy
API Proxy 是傳入要求與後端服務之間的介面。Proxy 實體包含 Apigee 在處理用戶端要求和後端回應時執行的指令和政策。
API 產品
用於發布 API 的實體。API 產品會發布至開發人員入口網站，供外部開發人員使用。API 產品提供介面，可存取一或多個已發布的 API。介面 (可能使用 OpenAPI 規格說明) 可能包含一或多個 API Proxy 處理的 API 要求組合。
機構中的使用者會建立 API 產品。這麼做時，他們可以將任意中繼資料附加至每個 API 產品。其中一種常用的中繼資料類型可以定義服務方案，這類方案可指定 API 呼叫的存取限制、規定安全需求、允許監控和分析，以及提供其他功能。
Apigee 會收集 API 產品的數據分析資料。
API 供應商
建立及管理 API Proxy 和產品的人員或實體。用戶端應用程式開發人員可存取這些已發布的 API。
應用程式開發人員
機構組織包含一或多位開發人員，他們會建構應用程式，以使用機構組織定義的 API (以 API 產品形式發布)。開發人員可使用 API，但無法建立 API 或在機構中執行任何其他動作。
開發人員可以是貴公司內部人員、合作夥伴，也可以是外部開發人員，他們可能需要付費才能存取您的 API。您可以將開發人員視為使用您 API 的客戶。
開發人員必須先在貴機構註冊，才能註冊應用程式，並取得 API 金鑰或其他用戶端憑證，以存取您的 API。身為 API 提供者，您可以自行決定如何在機構中新增、更新或移除開發人員。您可以透過 UI 手動新增，建立開發人員入口網站，透過網站註冊，或使用 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 (即使開發人員應用程式的註冊代表仍存在於貴機構中)。或者，您也可以撤銷開發人員的存取權，這樣一來，該開發人員註冊的所有應用程式憑證都會失效。撤銷作業可以復原。
Apigee 建立應用程式憑證時，您可以指定到期時間，讓開發人員在特定時間後必須取得新的金鑰或憑證。
Apigee 使用者
Apigee 使用者是機構的 API 團隊成員，包括管理員、API Proxy 和 API 產品建立者，或是監控數據分析和其他統計資料的使用者。使用者是使用 Apigee 開發人員建構應用程式的人員。在大多數情況下，本文件會使用「使用者」一詞來指稱 Apigee 使用者。
管理員可以將使用者新增至機構。
每位使用者可具備不同的角色和存取權限，舉例來說，您可以將部分使用者定義為機構管理員和營運管理員，授予他們修改機構及其元件的權限，並將其他使用者定義為有權建立 API Proxy 和 API 產品，但無權修改其他使用者的使用者。
使用者可以同時屬於多個機構。舉例來說，貴公司可能會在 Apigee 上定義多個機構，以支援不同的開發人員社群，即使內部人員建構所有 API Proxy 和 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"]],["上次更新時間：2025-08-19 (世界標準時間)。"],[[["\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)."]]
