Creating an API plan

Configure an API plan to package a list of APIs to expose for access. Unless you add the API to a pland, the API is not exposed for access.

About this task

Attention: Because the synchronization interval is 1 second, do not use the local cache first to enforce the rate limit with a 1-second interval. With this configuration, each peer can use all available tokens during the interval. For example, a configuration of 10 tokens per second with 3 peers results in a condition where each peer can use 10 tokens.

To configure an API plan, provide the following settings.

The name of the plan.
The ID, name, version, and title of the product that the API plan belongs to. A product makes a set of APIs and plans into one offering to make available to API developers. For more information, see the API Connect information about products.
The ID and name of the space that the product belongs to. When space is enabled for a catalog, the catalog can be partitioned to multiple spaces. Each space is used by a different API provider development team and has its own set of management capabilities that pertain specifically to the APIs in that space. Spaces enable each team to manage their APIs independently. For more information, see the API Connect information about spaces.
The APIs to package into the plan.
The operations to exclude. When an operation is excluded from the plan, API requests cannot access the API operation through the plan.
The rate limit schemes that are specific to certain operations. When an operation-specific rate limit scheme is defined, this scheme is enforced instead of the rate scheme in the plan.
The scope to apply the rate limit schemes to. You can apply the rate limit schemes per application or per client ID. For example, an application has client IDs client1 and client2. The rate limit is 10 calls per hour.
- When the rate limit is per application, the limit is 10 calls to the API per hour from either client1 or client2.
- When the rate limit is per client ID, the limit is 10 calls to the API per hour from client1 and from client2.
GraphQL schema options that specify lists of GraphQL schema elements to remove during validation and introspection. The options apply only to the API specified in the GraphQL schema options configuration. For more information, see Configuring GraphQL schema options.
Whether to use a rate limit definition group or named rate limit and burst limit schemes to enforce preflow limits.
- When rate limit definition group is enabled, named preflow limit schemes are not available. Specify a group. For more information, see Configuring a rate limit definition group.
- When rate limit definition group is disabled, define preflow limit schemes.
  Burst limit schemes help prevent usage spikes that might damage infrastructure. The burst limit takes higher priority than the rate limit. When a message arrives within an interval, the message is first checked against the burst limit scheme.
  - When the burst limit is exceeded, the message is rejected.
  - When the burst limit is not exceeded, the API gateway proceeds to check the message against the rate limit scheme.
  When and whether the burst limits and rate limits are applied depends on whether the API collection enforces pre-assembly limits. For more information, see API rate limits.
The assembly rate limits to enforce when added to a rate limit assembly action. Specify whether to use rate limit definitions or define limits in the plan. You can add one or more types of rate limit schemes.
- The assembly rate limit schemes to enforce.
- The assembly burst limit schemes to enforce. The burst limit prevents usage spikes that might damage the infrastructure. The burst limit takes priority over the rate limit. When a message arrives within an interval, the message is first checked against the burst limit schemes and then against the rate limit schemes.
  - When the burst limit is exceeded, the message is rejected.
  - When the burst limit is not exceeded, the API gateway checks the message against the rate limit schemes.
- The assembly count limit schemes to enforce. The count limit restricts the number of requests in progress for subsequent actions. When the count limit is exceeded, an error is generated.

Procedure

In the search field, enter plan
From the search results, click API plan.
Click Add.
Define the basic properties - Name, administrative state, and comments.
Optional: Specify the name of the plan.
Optional: Specify the product ID.
Optional: Specify the product name.
Optional: Specify the product version.
Optional: Specify the product title.
Optional: Specify the space ID.
Optional: Specify the space name.
Specify a list of APIs to package into the plan.
Optional: Specify GraphQL schema options.
Specify the operations to exclude from the plan.
On the Plan rate Limits tab, configure API plan rate limits.
Specify the operation rate limit to override the rate limit scheme for certain operations.
Specify the rate limit scope to enforce on the plan.
Specify whether to use a rate limit definition group to enforce preflow limit schemes.
When rate limit definition group is enabled, specify a group.
When rate limit groups are disabled, add preflow limit schemes to enforce on the plan. Follow these steps to add rate limits or burst limits. The Use API name, Use application ID, Use client ID, Dynamic value, and Weight expression settings do not apply to preflow limit configurations in the API plan. These settings are ignored.
1. Click Add.
2. Specify the name for the limit scheme.
3. Specify the maximum rate to allow.
4. Optional: Specify the time interval.
5. Optional: Specify the time unit.
6. Optional: Specify to enable hard limit.
7. Optional: Specify to use the local cache first to enforce the limit. In peer group mode, the local cache first can prevent transaction delays if communication problems arise across the peer group. However, the transaction count is less precise when this setting is enabled.
8. Optional: Specify to enforce the limit on the client rather than on an internal component. When exceeded, client limits return a 429 and nonclient limits return a 503. When disabled, limit information is not included in the response header.
9. Click Apply.
10. Optional: Repeat this step to add another limit scheme.
Optional: On the Assembly rate limits tab, add assembly limits.
Specify whether to use rate limit definitions instead of defining assembly rate limits in the plan.
Optional: To define assembly rate limits in the plan, follow these steps to add assembly rate limits, assembly burst limits, or assembly count limits.
1. Click Add.
2. Specify the name for the limit scheme.
  Assembly limits defined in different configurations, including an API gateway, API collection, or API plan, must have unique names. If two limits with the same name are in an assembly and both are applied, then information about only one is included in the limit response headers.
3. Specify the maximum rate to allow.
4. Optional: Specify the time interval.
5. Optional: Specify the time unit.
6. Optional: Specify to enable hard limit.
7. Optional: Specify to use the local cache first to enforce the limit. In peer group mode, the local cache first can prevent transaction delays if communication problems arise across the peer group. However, the transaction count is less precise when this setting is enabled.
8. Optional: Specify to enforce the limit on the client rather than on an internal component. When exceeded, client limits return a 429 error code, and nonclient limits return a 503 error code. When set to off, limit information is not included in the response header.
9. Optional: Specify to include the API name in the limit key.
10. Optional: Specify to include the application ID in the limit key.
11. Optional: Specify to include the client ID in the limit key.
12. Optional: Specify the dynamic value string for the limit, which contains one or more context variables.
  The dynamic value makes it possible to use a context variable to enforce the limit based on parameters that are not defined in the scheme. The context variable can be set in a GatewayScript action and then included in the dynamic value.
  The following example uses the context object in a GatewayScript action to add the variable my.server to the API context.
```
context.set("my.server", "server34")
```
  The dynamic value can then include the my.server variable, which resolves to the server name server34.
  
  The default value is an empty string.
13. Optional: Specify a JSONata expression that assigns a weight value to the transaction.
  
  You use a subset of JSONata notation to define the expression. For more information, see JSONata and assembly actions.
  
  For each API call, the applied limit is the value that the weight expression computes. The default setting is 1. If the weight expression evaluates to a value that is less than or equal to 0, it is set to 1. An empty string results in an error.
14. For an assembly count limit, specify whether to autodecrement the count limit for each transaction. When enabled, the count limit is decremented at the end of the assembly. The decrement amount is the total incremented amount minus any decrement actions in the rate limit assembly action. You do not need to define decrement actions explicitly unless you want the decrements to occur at specific points in the assembly. When set to off, you must explicitly define a decrement action for each corresponding increment action. For more information, see Count limits guidelines.
15. Click Apply.
16. Repeat this step to add another limit scheme.
To use rate limit definitions for enforcement in the rate limit assembly action, follow these steps to specify rate limit, burst limit, or count limit definitions.
1. Specify a short name for the limit definition.
2. Specify the limit definition.
3. Click Apply.
4. Repeat this step to add another limit definition.
Click Apply to save changes to the running configuration.
Click Save to save changes to the persisted configuration.