The following sections introduce you to API products and related key concepts.
As an API provider, you create API products to bundle your APIs and make them available to app developers for consumption. You can think of API products as your product line.
Apigee recommends that you maintain a one-to-one relationship between your OpenAPI Specifications, API proxies, and API products.
The API resources bundled in an API product can come from one or more APIs, so you can mix and match resources to create specialized feature sets, as shown in the following figure.
An API product offering a low access limit, such as 1000 requests per day, for a bargain price. A second API product providing access to the same resources, but with higher access limit and a higher price.
A free API product offering read-only access to resources. A second API product providing read/write access to the same resources for a small charge.
In addition, you can control access to the API resources in an API product. For example, you can bundle resources that can be accessed by internal developers only or by paying customers only.
API products are the central mechanism for authorization and access control to your APIs. In Apigee, API keys are provisioned, not for APIs themselves, but for API products. In other words, API keys are provisioned for bundles of resources with an attached service plan.
The requesting app is permitted to access a particular API resource.
The requesting app has not exceeded the permitted quota.
If defined, the OAuth scopes defined in the API product match those associated with the access token presented by the app.
Note: See also this Apigee Community article: Making sense of API Product configuration.
Review the following key concepts before you create your API products.
When you register a developer's app in your organization, the app must be associated with at least one API product. As a result of pairing an app with one or more API products, Edge assigns the app a unique consumer key.
Apps with multiple credentials are not supported by the integrated portal.
When the API uses API key verification, the app must pass the consumer key directly.
When the API uses OAuth Token verification, the app must pass a token which has been derived from the consumer key.
API key enforcement doesn't happen automatically. Whether using the consumer key or OAuth tokens as request credentials, the API Proxy validates the request credentials in your API proxies by including a VerifyAPIKey policy or an OAuth/VerifyAccessToken policy, in the appropriate flow. If you do not include a credential enforcement policy in your API Proxy, any caller can invoke your APIs. For more information, see Verify API Key policy.
Get the credentials that are passed with the request. In the case of OAuth token verification, Edge verifies that the token is not expired, and then looks up the consumer key that was used to generate the token.
Retrieve the list of API products to which the consumer key has been associated.
Confirm that the current API Proxy is included in the API Product, and if the current resource path (URL path) is enabled on the API Product.
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.
If all of the above checks pass, the credential verification succeeds.
Bottom line, Edge automatically generates consumer keys, but API publishers have to enforce key checking in API proxies by using appropriate policies.
By default, all requests to obtain a key to access an API product from an app are automatically approved. Alternatively, you can configure the API product to approve keys manually. In this case, you will have to approve key requests from any app that adds the API product. For more information, see Register apps and manage API keys.
Quotas can protect your backend servers for high traffic, and differentiate your product line. For example, you might want to bundle resources with a high quota as a premium product and use the same bundle with a lower quota as a basic product. A quota can help protect your servers from being overwhelmed if a product is popular and receiving a large amount of requests.
For information on configuring quota, see Quota policy. For information on on using product quota settings in quota policies, see the following community article How do the quota settings on an API product interact with quota policies in an API proxy?.
As an added level of security, you can define any OAuth scopes, as a comma-separated list, that must be present in access tokens sent through the product. When you're creating a product, you need to be aware of all the scopes your organization uses. The scopes you add to a product must match existing scopes or the product is not secure.
For more information about using scopes with Edge OAuth policies, see Working with OAuth2 scopes.
When defining an API product, you can set the following acess levels.
Public You can add public API products to your developer portal. Then, when developers create or modify their developer apps in the portal, they can view and select the public API products.
You cannot add Private or Internal only API products to your developer portal. To make Private or Internal only API products available to app developers, you must add them manually to a registered app from the Edge management UI or API, as described in Register apps and manage API keys.
Once added, the developer sees the API product associated with the app in your portal, as described in Managing API products in an app.
Note: If the app developer disables access to an API product that is internal or private, the API product is removed from the app and must be re-added manually by the portal administrator.