Send Docs Feedback

Note: Most user interface tasks can be performed in Edge Classic or the New Edge experience. For an overview, getting started topics, and release notes specific to the New Edge experience, see the docs.

Create API products

You can create an API product in the Apigee Edge management UI at https://enterprise.apigee.com or with the management API. This procedure shows the management UI version. For the API version, (see Using the Edge management API to Publish APIs).

For an overview of API products, see What is an API product?.

In order for an API product to work correctly, do the following:

  • Include the appropriate security policy in your API proxies, such as Verify API Key or OAuth v2.0. The API product uses API keys and/or OAuth access tokens to enforce API access. For more, see API keys and OAuth home.
  • Add API proxies and/or resources to your API product to restrict access. Otherwise, any app associated with the API product will be able to make calls to any API in your Edge organization.

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 Name. This will be the internal name of the product. You cannot edit the name once the product is created. You cannot use special characters in the name. 
  5. Enter a Display Name. The display name displays in the UI. The Display Name field is automatically populated using the contents of the Name field, but you can edit it. You can change the display name at any time by editing the product. You can use special characters in the display  name. 
  6. Optionally, enter a Description for the API product. 
  7. Add at least one API proxy to the product. Click +API Proxy.
    This limits access to the API proxies listed. You'll configure resources later in this procedure.
    If you don't select an API proxy, any app associated with the product can make calls to any API in your entire organization.
  8. Environment: Select the environments the product will allow access to. For example, select the test environment for internal-facing products or the prod environment for public-facing products.
    If you select no environments, the product allows access to all environments.
  9. Specify an Access level.
    • Public - When developers create or modify their developer apps in a Developer Services Portal, they can see and select public products.
    • Internal only or Private - There is no functional difference between these two options. When an API product is internal only or private, the product doesn't appear in the Developer Services Portal. To let a developer use the product, you must manually add the product to a developer app in the management UI or with the management API. Once you do this, the developer sees the product associated with her app in the Developer Services Portal.
  10. 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. To manually approve keys:
    • UI: Publish > Developer Apps > developer_app > click Edit to edit the app > Approve
    • API: Use the Developer App Keys API.
  11. Entering a quota Quota limit does not automatically enforce restrictions on the number of calls that can be made through the product. For more information, see the Quota section above.

    Enter a quota limit that you want to reference from quota policies.

  12. Optionally, if you are using OAuth with the API product, enter the Allowed OAuth Scopes that you want the product to allow (such as 'Read' or any other scopes that apps will send with their API calls). You can specify multiple scopes as a comma-separated list. 

    For more about scopes, see Working with OAuth2 scopes.
  13. In the Resources section, add an API Proxy, Revision, and Resource Path to the API product.

    See also this Apigee Community article: Making sense of API Product configuration

    Adding Resource Paths lets you further restrict API access with relation to the API proxies included in the product. For example, let's say you add a "music" API proxy to the product with a base path of /music. That means the product allows calls to /music.

    However, you want the product to allow access to only the venues resource, which has a URI of /music/venues. By adding a /venues Resource Path to the product, the product allows calls to only that URI. For example, calls to /music/venues?name=paramount go through, but calls to /music/artists?name=Jack%Johnson get rejected.

    You can add Resource Paths either by selecting one from an existing API proxy API Proxy, Revision, and a Resource Path (then click Import Resource), or by clicking +Custom Resource and adding a free-form resource pattern.
    You can select a specific path, or you can select the base path and all subpaths by specifying the resource path as '/'.

    The Resource Path also supports the wildcards /** and /*. The double asterisk wildcard indicates that all sub-URIs of the base path are supported (but not the base path). A single asterisk indicates that only URIs one level down from the base path are supported.

    See Configuring the behavior of a Resource Path of '/', '/*', and '/**' below for more.
  14. (Optional) You can also add up to 18 custom attributes to an API product. Custom attributes are key/value pairs that can be used in many ways, including helping control API proxy execution. For example, you could create a custom attribute called deprecated with a value of true or false. In your API proxy flow, you could check the value of the API product's deprecated attribute (for example, using the verifyapikey.{policy_name}.apiproduct.deprecated variable that is automatically available after you create the custom attribute). If its value is true (deprecated), you can throw an error with the Raise Fault policy.
  15. Save your product.

Editing an API product

To improve performance, API product information, such as resource path definitions, are cached for a short period of time (approximately five minutes). As a result, edits that you make to an API product may not take effect immediately.

To edit an API product:

  1. Login to the Edge management UI at https://enterprise.apigee.com.
  2. Click the Publish tab, then Products.
  3. Click the name of the API product that you want to edit.
  4. Click Edit on the API product page.
  5. Edit the fields, as required.
  6. Click Save.

Configuring the behavior of a Resource Path of '/', '/*', and '/**'

The following table describes the default behavior of an API product for different Resource Paths. In this example, the API proxy has a base path of /v1/weatherapikey. The API product resource path applies to the path suffix after the base path.

See also this Apigee Community article: Making sense of API Product configuration

Request path Allowed for / Allowed for /* Allowed for /** Allowed for /*/2/**

/v1/weatherapikey

Y

N

N

N

/v1/weatherapikey/

Y

N

N

N

/v1/weatherapikey/1

Y

Y

Y

N

/v1/weatherapikey/1/

Y

Y

Y

N

/v1/weatherapikey/1/2

Y

N

Y

N

/v1/weatherapikey/1/2/

Y

N

Y

Y

/v1/weatherapikey/1/2/3/

Y

N

Y

Y

/v1/weatherapikey/1/a/2/3/

Y

N

Y

N

By default, a Resource Path of '/' in an API product supports the base path and all sub-URIs. 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.

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 a URI that has anything after the '/'. If you make this change, then in the table above, only the first two rows under "Allowed for '/'" would contain "Y".

Monetization: If your products will be used in monetization, where product resource paths are used to define transaction recording policies, use '/**' explicitly. Monetization treats '/' as base-path-only and not '/**'. 

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.

Apigee Edge for Private Cloud customers can make a request in the form below to set the property on an organization:

curl -u username:password -X POST -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \
"<Organization name='myorg' type='trial'> \
<Properties> \
<Property name='features.isSingleForwardSlashBlockingEnabled'>true</Property> \
<!-- other existing org properties here --> \
</Properties> \
</Organization>"

Be sure to include other existing organization properties in this API call. If you don't, the old properties are wiped out and replaced by the property set in this call.

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?