[[["易于理解","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-04。"],[[["\u003cp\u003eAPI products are bundles of one or more API operations, serving as the primary mechanism for access control to APIs within Apigee and Apigee hybrid.\u003c/p\u003e\n"],["\u003cp\u003eAPI products can be configured with quotas and various pricing models to manage usage and differentiate service levels, such as Free, Basic, or Premium tiers.\u003c/p\u003e\n"],["\u003cp\u003eEach operation within an API product can define specific access controls, including resource paths, HTTP methods, and quotas, which take precedence over product-level quotas.\u003c/p\u003e\n"],["\u003cp\u003eAPI keys are assigned to developer apps based on their association with API products, and these keys must be validated using policies like VerifyAPIKey or OAuthv2 within API proxies to enforce access.\u003c/p\u003e\n"],["\u003cp\u003eAPI products can have different access levels like Public, Private, or Internal only, to manage their visibility and availability to developers through portals, with distinct handling for each type.\u003c/p\u003e\n"]]],[],null,["# Introduction to API products\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\nThe following sections introduce you to API products and related concepts such as quotas and\nAPI keys.\n\nWhat is an API product?\n-----------------------\n\nAs an API provider, you create API products to bundle your APIs and make them available to app\ndevelopers for consumption. You can think of API products as your product line.\n\nSpecifically, an API product bundles together one or more operations. An operation specifies\nan API proxy and resource paths that can be accessed on that proxy. An operation can also\nlimit access by HTTP methods and by quota.\n| **Note:** See also this Apigee Community article: [Making\n| sense of API Product configuration](https://community.apigee.com/articles/38309/making-sense-of-api-product-configuration.html).\n\nAPI products are the central mechanism for access control to your APIs. By defining one or more\nAPI products in a developer app, you\ncan restrict access to proxies with an API key. In Apigee, API keys are\nprovisioned, not for APIs themselves, but for API products. In other words, API keys are\nprovisioned for bundles of operations that define a product line or specific service plan.\n\nCommon use cases\n----------------\n\nYou can create multiple API products that contain operations to address specific use cases.\nFor example, you can create an API product that bundles a number of operations that contain\nmapping resources to enable developers to easily integrate maps into their applications.\n\nIn addition, you can use API products to define pricing levels based criteria such the as:\n\nThe number of requests:\n\n- Premium: Unlimited requests per day\n- Basic: Up to 1000 requests per day\n- Free: Up to 100 requests per day\n\nOr level of access:\n\n- Premium: Read, write, update and delete\n- Basic: Read and update\n- Free: Read-only\n\nOr any combination of the above:\n\n- Extra Premium: Read and write unlimited times per day\n- Premium: Read and write up to 1000 requests per day\n- Basic: Read and write access up to 100 times per day\n- Free: Read up to 1000 times per day\n- Free: Read-only access limited to 100 requests per day\n\n| **Note:** Apigee recommends that you maintain a one-to-one relationship between your OpenAPI Specifications, API proxies, and API products.\n\nRequirements\n------------\n\n| **Important:** These requirements apply to API products created in [Pay-as-you-go](/apigee/docs/api-platform/reference/pay-as-you-go-updated-overview) only.\n\nAPI products that are part of Pay-as-you-go must include:\n\n- extensible proxies built with flow hooks\nor\n- extensible policies such as the [VerifyAPIKey policy](/apigee/docs/api-platform/reference/policies/verify-api-key-policy) or [OAuthv2 policy](/apigee/docs/api-platform/reference/policies/oauthv2-policy)\n\nOperations\n----------\n\nAn *operation* is a group of attributes that restrict access to one or more API proxies based\non criteria such as resource path, HTTP method, and quota. An operation includes these attributes:\n\nAPI keys\n--------\n\nWhen you register a developer's app in your organization, the app must be associated with at\nleast one API product. As a result of pairing an app with one or more API products, Apigee\nassigns the app a unique consumer key. See also\n[Controlling access\nto your APIs by registering apps](/apigee/docs/api-platform/publish/creating-apps-surface-your-api).\n| **Note:** Apps with multiple credentials are not supported by the integrated portal.\n\nThe consumer key or access token act as request credentials. The app developer embeds the\nconsumer key into the app, so that when the app makes a request to an API hosted by Apigee,\nthe app passes the consumer key in the request in one of the following ways:\n\n- When the API uses API key verification, the app must pass the consumer key directly.\n- When the API uses OAuth Token verification, the app must pass a token which has been derived from the consumer key.\n\nAPI key enforcement doesn't happen automatically. Whether using the consumer key or OAuth tokens\nas request credentials, the API proxy validates the request credentials in your API proxies\nby including a [VerifyAPIKey policy](/apigee/docs/api-platform/reference/policies/verify-api-key-policy) or a `VerifyAccessToken` policy configuration (see\n[OAuthv2 policy](/apigee/docs/api-platform/reference/policies/oauthv2-policy)) in the appropriate flow. If you do not include a credential enforcement\npolicy in your API Proxy, any caller can invoke your APIs.\n\nTo verify the credentials passed in the request, Apigee performs the following steps:\n\n1. Get the credentials that are passed with the request. In the case of OAuth token verification, Apigee verifies that the token is not expired, and then looks up the consumer key that was used to generate the token.\n2. Retrieve the list of API products to which the consumer key has been associated.\n3. Confirm that the current API Proxy is included in the API Product, if the current resource path (URL path) is enabled on the API Product and, if included in the product, that the request uses a specified HTTP verb.\n4. Verify that the quota, if specified has not been exceeded.\n5. Verify that the consumer key is not expired or revoked, check that the app is not revoked, and check that the app developer is active.\n\nIf all of the above checks pass, the credential verification succeeds.\n\nBottom line, Apigee automatically generates consumer keys, but API publishers have to enforce\nkey checking in API proxies by using appropriate policies.\n\nKey approval\n------------\n\nBy default, all requests to obtain a key to access an API product from an app are automatically\napproved. Alternatively, you can configure the API product so that you must approve keys manually.\nThe setting for this is described in\n[Managing API products](/apigee/docs/api-platform/publish/create-api-products#productdetails).\nIn this case, you will have to approve key requests from any app that adds the API product. For\nmore information, see\n[Controlling access to your APIs by registering apps](/apigee/docs/api-platform/publish/creating-apps-surface-your-api).\n\nQuotas\n------\n\nQuotas can protect your backend servers from high traffic variances and differentiate your\nproduct line. For example, you can bundle resources with a high quota as a premium product,\nand use the same bundle with a lower quota as a basic product. Quotas can help protect your\nservers from being overwhelmed if a product is popular and receives a large amount of requests\nin a short period of time.\n\nYou can specify a quota that applies to all API proxies included with the API product, or\nspecify operation-level quotas. A quota specified in an operation takes precedence over a\nquota set at the API product level.\n\nSetting quota limits on an API product does not\nautomatically enforce quota. It's simply a default limit that can be referenced in quota policies.\nHere are some advantages of setting a quota on the product for quota policies to reference:\n\n- Use a [Quota policy](/apigee/docs/api-platform/reference/policies/quota-policy) to apply a uniform setting across all API proxies in an API product.\n- If you change the API product's quota settings at runtime, Quota policies automatically reference the updated quota settings.\n\nFor more information, see the following:\n\n- [Quota policy](/apigee/docs/api-platform/reference/policies/quota-policy)\n- [How\n do the quota settings on an API product interact with quota policies in an API proxy?](https://community.apigee.com/questions/1488/how-do-the-quota-settings-on-an-api-product-intera.html).\n\nOAuth scopes\n------------\n\nYou can define OAuth scopes as a comma-separated list that must be present in access tokens\nassociated with the product. For more information about using scopes with Apigee OAuth\npolicies, see [Working with\nOAuth2 scopes](/apigee/docs/api-platform/security/oauth/working-scopes).\n\nAccess levels\n-------------\n\nWhen defining an API product, you can set the following access levels:"]]
