Plugins

API7 Enterprise plugins extend API7 Enterprise's functionalities to meet organization or user-specific requirements in traffic management, observability, security, request/response transformation, serverless computing, and more.

API7 Enterprise offers many plugins that can be customized and orchestrated to satisfy your requirements. These plugins can be globally enabled on every incoming request, or locally bound to other objects, such as routes, services, or consumers.

If existing API7 Enterprise plugins do not meet your needs, you can also write your own plugins in Lua or other languages such as Java, Python, Go, and Wasm.

Plugins Execution Lifecycle

The configuration of the plugin is then checked against the defined JSON Schema to make sure the plugin's configuration schema is correct.

When a request goes through API7 Enterprise, the plugin's corresponding methods are executed in one or more of the following phases: rewrite, access, before_proxy, header_filter, body_filter, and log. These phases are largely influenced by the OpenResty directives.

To learn more about phases for your custom plugins development, see the plugin development how-to guide (coming soon).

Plugins Execution Order

In general, plugins are executed in the following order:

1. Plugins in global rules

   1. plugins in the rewrite phase
   2. plugins in the access phase

2. Plugins bound to other objects

   1. plugins in the rewrite phase
   2. plugins in the access phase

Within each phase, you can define a new priority value in the _meta.priority attribute of the plugin, which takes precedence over the default plugin priority during execution. Plugins with higher priority values are executed first.

Plugins Merging Precedence

When a plugin is configured both globally in a global rule and locally in an object (such as a route), both plugin instances are executed sequentially.

However, if a plugin is configured locally on multiple objects, only one copy of the configuration is used. During execution, plugins configured in these objects are merged in a specific order of precedence:

Consumer > Route > Service

Therefore, if a plugin has different configurations in different objects, the plugin configuration with the highest order of precedence will be used.

Plugins Execution Filter

By default, all plugins are triggered by incoming requests that match the configured rules in routes. Sometimes you may want more granular control over plugin execution.

API7 Enterprise allows dynamic control over plugin execution by applying the _meta.filter configuration to the plugins. The configuration supports the evaluation of a wide range of built-in variables and API7 Enterprise expressions.

Plugin Global Rules

A plugin global rule object is used to create plugins that are triggered on every incoming request. Global rules will be executed before other plugins are locally bound to objects. Certain plugins, such as rate limiting and observability plugins, are frequently enabled globally to provide consistent and comprehensive protection for APIs.

This diagram illustrates how to enable the prometheus plugin globally for incoming requests and enable proxy-rewrite plugin on a route to modify the request's HTTP header.

This example enables two different plugins as a global rule and on a route. If the same plugin is configured on both objects, the plugin will be executed sequentially.

Plugin Metadata

Plugin metadata is used to configure the common metadata fields of all plugin instances sharing the same plugin name. It is useful when a plugin is enabled across multiple objects and requires a universal update to their metadata fields.

The following diagram illustrates the concept of plugin metadata:

By default, the log_format on the plugin metadata object should apply the same log format uniformly to both syslog plugins. However, since the syslog plugin on the /order route has a different log_format, requests to this route will generate logs in the log_format specified by the plugin in the route.

If a plugin field is defined in both the plugin metadata and another object, the definition of the object takes precedence over that in the plugin metadata.

Plugin metadata objects should only be used for plugins that have metadata fields. For more details on which plugins have metadata fields, see the plugin reference guide (coming soon).