Was this Helpful?

Create an API product in the Apigee Edge management UI at https://enterprise.apigee.com. You must create your API products using the Edge management UI before you can make them available on your developer portal.

You can set up an API product with no resources to make it easier to get up and running quickly. Just create a single API product and provide the base path along with a wildcard for the resource. The wildcard will be interpreted by the system at runtime as meaning that any requested resource in the URI tree below the wildcard is permitted. See the procedure below for more information on using a wildcard in an API product definition.

You can also create an API product by using the Edge management API. See Using the Edge management API to Publish APIs for more.

Before you begin

This section explains a few key concepts related to API products. It's helpful to familiarize yourself with these concepts before you create a new API product.

Keys

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. When the app makes a request to an API resource in an API product, the request must include its unique API key.

API key enforcement doesn't happen automatically. You must enforce API key checking in your API proxies with a policy, such as the Verify API Key policy. Without some type of key enforcement policy, anyone can make calls to your APIs. For more information, see Verify API Key policy.

Bottom line, Edge automatically generates keys, but you have to enforce key checking in your APIs.

Manual key approval

By default, all key requests to an API product from an app are automatically approved. You can instead choose to approve keys manually. If you set this option in the Edge management UI when creating the product, you will have to approve key requests that come in from any app that adds the API product. See Registering apps for more.

Quotas

You can control the traffic flow for each API product by setting up a quota. 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 particularly popular. See Quota policy for more.

Scope

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 Authorize requests using OAuth 2.0.

Creating an API product

To create a new API product:

  1. Login to the Edge management UI at https://enterprise.apigee.com. (You can obtain a free account at https://accounts.apigee.com/accounts/sign_up.)
  2. Click the Publish tab, then Products
  3. Click the (+) Product button.
  4. On the Add Products page, enter a Display Name and Description for the API product.
  5. Select the test environment for internal-facing products or the prod environment for public-facing products.
  6. Specify an Access level. This option determines who can access the product. You can use these levels to control access at different stages of development.
    Only products marked Public are available to developers in the Apigee developer portal. For example, you can set a product to Internal Only while it's in development and then change access to Public when it's ready to release on the portal. API products marked as Private do not appear on the portal but can be accessed by external developers.
    You can determine the Access level of an API product by examining the attributes array of the API product. See Get API Product for more. The array is in the form:

    "attributes": [
        {
          "name": "access",
          "value": "private"
        }
      ]
  7. Select a Key Approval Type as Automatic or Manual.
    If you select automatic key approval, all key requests that come in from any app that uses this API product are automatically approved. If you select manual key approval, you will have to approve key requests that come in from any app that uses this API product.
  8. Enter a Quota limit and select a time period (week, hour, minute, second).
    This sets up a quota for your product that limits the number of calls the product accepts in a given time period. For example, a Quota of 10 requests every 24 hours means that the quota will be calculated over the course of 24 hours.
  9. Optionally, if you are using OAuth with the API product, enter the Allowed OAuth Scopes for the product (such as 'Read'). You can specify multiple scopes as a comma-separated list. 
    The OAuth scope should match one of the scopes you defined in your security policy. If they don't match your API may not be secure.
  10. In the Resources section:
    • Add an API Proxy and resource. Select a proxy Revision, and a Resource Path, and then select Import Resource.

      You can select a specific path, or you can select all subpaths with a wildcard. Wildcards (/** and /*) are supported. The double asterisk wildcard indicates that all sub-URIs are included. A single asterisk indicates that only URIs one level down are included.

      By default, a Resource Path of '/' supports the same resources as '/**' as well as the Base Path defined by the API proxy. For example, if the Base Path of the API proxy is /v1/weatherapikey, then the API product supports requests to /v1/weatherapikey and to any sub-URIs, such as /v1/weatherapikey/forecastrss, /v1/weatherapikey/region/CA, etc. See the section below on changing the behavior of this default.

    • Add an explicit resource path by selecting the +Custom Resource button.
    • Add an API proxy by selecting the +API Proxy button.
  11. Save your product.

Configuring the behavior of a Resource Path of '/'

By default, a Resource Path of '/' in an API product supports the same resources as '/**' as well as the Base Path defined by the API proxy. You can change this default so that a Resource Path of '/' corresponds only to the Base Path of the API proxy, meaning the API product will not allow access to sub-URIs.

To change the default, a system administrator must set the value of the features.isSingleForwardSlashBlockingEnabled property on your organization to true. Cloud customers can make that request to Apigee Support. OPDK customers can make a request in the form below to set the property on an organization:

curl -u uName:pWord -X POST -H "Content-type:application/xml" http://edgeHost:8080/v1/o/myorg -d \
"<Organization name='myorg' type='trial'> \
<Properties> \
<Property name='features.isSingleForwardSlashBlockingEnabled'>true</Property> \
</Properties> \
</Organization>"

Configuring an API proxy added to a product

An app developer chooses the API product to access when the developer registers the app. The developer then receives a key that the app must pass on every request to a resource defined by the product.

However, enforcement of the key is performed at the API proxy level, not by the API product itself. Therefore, you must ensure that all API proxies, and the corresponding resources defined by those API proxies, implement some form of key validation. For example, you can define an API proxy to perform key validation by using the VerifyAPIKey policy. Or, an API proxy could use OAuth 2.0 as defined by the OAuth v2.0 policy. For more, see API keys and OAuth.

Deleting resources 

You can delete resources that you've added to an API product. You might want to do this if a resource is malfunctioning or requires more development. When deleted, that resource is no longer part of the API product. Any app that uses the API product can no longer access the deleted resource. Deleted resources are removed from the product but are not deleted from the system, so they can still be used by other products.

To delete a resource

  • In the API Resource Paths for Product section of the product details window, locate the resource you want to disable, then click Delete in the Actions column.

     

Help or comments?

  • Something's not working: See Apigee Support
  • Something's wrong with the docs: Click Send Feedback in the lower right.
    (Incorrect? Unclear? Broken link? Typo?)