Examples

Last updated: 2020-03-23 15:29:12

PDF

Operation Scenarios

To successfully call a service after it is published, you need to create a key pair and a usage plan and bind them to the service environment.
This document describes how to configure a user-specific usage plan and make it available to the users.

Prerequisites

  1. You have created a service and created and debugged an API to ensure that the API is valid and responsive.
  2. You have published a service to a certain environment, such as the release environment.

Directions

Creating key pair

  1. Log in to the API Gateway Console and click Key on the left sidebar to enter the key management page.
  2. Click Create in the top-left corner and enter a key name in the pop-up dialog box.
    Key name: up to 50 letters, digits, and underscores.
  3. Click Submit and the system will automatically generate a key pair (SecretId and SecretKey).

Creating usage plan

  1. On the left sidebar, click Usage Plan to enter the usage plan list page.
  2. Click Create in the top-left corner and enter the configuration information as prompted.
  3. Click Submit to complete the creation.

Binding usage plan to key pair

  1. On the Usage Plan page, click the ID of the target usage plan to enter the usage plan details page.
  2. On the usage plan details page, click Bind Key.
  3. Check the SecretId to be bound and click Submit to complete the binding.

Binding usage plan to service environment

  1. Select a created service on the Service list page, switch to the Usage Plan tab, and click Bind.
  2. In the usage plan binding window, select an effective environment and usage plan to be bound.
    Effective environments: publish, pre-publish, and testing
  3. Click Submit to complete the binding.

    If two usage plans need to be bound to the same environment, they cannot be bound to the same key pair.

After the above steps are completed, the created SecretId and SecretKey can be provided to the end user who can be authenticated with the provided SecretId and SecretKey through the second-level domain name of the service (or a bound private domain name) to access the APIs published in the service.