What is Policy?

A policy is a configurable component used in API Gateway to process requests from the client and responses returned from the Backend API according to specific rules.

Through policies you can perform the following actions:

• You can apply security rules. We define authentication (Basic Auth, OAuth2, OIDC, JWT, etc.) and authorization (role-based access control) mechanisms with policies.
• You can manage traffic. You can protect your APIs from overload with quotas (the number of requests that can be made within a certain period) and rate limiting policies per user or application.
• You can perform data transformation. You can convert incoming requests or returned responses into different formats (for example, converting XML to JSON, reformatting the data structure).
• You can customize error messages. You can translate the error messages returned by the system into corporate standards or a user-friendly language.
• You can implement business logic. You can define simple business rules at the API Gateway level using scripting languages ​​like JavaScript or Groovy, or conditional logic policies.
• You can enrich the message content. You can add headers to the request or response, include metadata, or mask sensitive data.

Policies are configuration-based. There's no need to write code or deploy applications. Instantly enable, update, or disable policies using drag-and-drop, parameter input, or configuration selections in the interface.

Purpose and Benefits of the Policy

Centralized Control: API behavior, security, and performance are managed from a single point, ensuring consistency across distributed systems and reducing management complexity.
Access Control Policies: Authentication, authorization, and access permissions to API resources are defined through policies. This prevents unauthorized access and ensures security.
Reusability: Once a policy is defined, it can be used by multiple APIs, endpoints, or services. This simplifies policy management and accelerates development.
Reducing Code Maintenance Overhead: Security, data transformation, and validation are performed in the gateway configuration, not in the code itself. This reduces code complexity in applications and lowers maintenance costs.
Consistency: Because all APIs are subject to the same policies, enterprise-wide security and performance standards are consistently applied. Exceptions are minimal.
Rapid Response and Resiliency: Policies can be instantly disabled, updated, or redeployed, enabling rapid response to security threats, resolving performance issues, or adapting to business rule changes.

Policy Usage Types

Local Policy

It is only valid in the API Proxy or API Proxy Group where it was created. If the API Proxy or API Proxy Group in which it is located is deleted, the policy is also deleted.

Export, import, activate, and deactivate operations can be performed in its current location.

Global Policy

Policies created on the Global Policies page can be used by multiple API Proxy or API Proxy Groups.

If a change is made to the global policy, all API Proxies and API Proxy Groups using the policy will be transferred to the "Redeploy Required" status.

The bulk deploy operation on this screen can be used to deploy all API Proxy/API Proxy Groups together.

Policy export, import, activate, and deactivate operations can also be performed from these screens.

Localizing the Global Policy:

A globally created policy may need to be customized when used in an API Proxy/API Proxy Group.

In this case, click on the policy added to the API Proxy/API proxy Group and click the "Localize" button in the upper right corner to make it local with a single click, as seen in the image below:

Where a Global Policy is Used:

Tracking which API proxies, API proxy groups, or policy groups a global policy is used in is critical for management and update processes.

On each policy detail page, the policy's usage information is displayed as shown in the image below:

Used in API Proxies Panel: This section displays the list of API proxies that use the policy.

Used in API Proxy Groups Panel: This section displays the list of API Proxy groups that use the policy.

Used in Policy Groups Panel: This section displays the list of policy groups that contain this policy.

Global and Local Policy Comparison

Policy Implementation Points

Policies can be implemented at three different levels:

Explanation

For detailed information about the order in which policies are applied in the message flow, the operating logic at the API Proxy Group/API Proxy/Endpoint levels, and the visual flow diagram, see the Message Flow and Policy Management page.

Viewing a Policy

Each global policy has a Policy View Page where users can view the current configuration.

Local Policies can only be viewed within the API Proxy or API Proxy Group in which they are located, while Global Policies can be viewed from the menu and the corresponding policy group's listing page.

From this page, you can edit, export, import, activate, deactivate, and delete operations.

Policy Structure

Despite their functional differences, policies share the same basic structure

General Information Panel

Each policy's name, description, and whether it's active or not are common fields.

Following the common fields are policy-specific configuration fields.

Conditions

Policies can be customized to run only when certain conditions are met.

Example:

• If the status parameter is "pending", execute.
• If the userId field is in the list #user1#user2#user3, execute.

This feature allows policies to operate dynamically and context-aware.

The image below shows an example condition where the selected policy is requested to run only if the value of the "status" parameter is "pending".

When the condition value comparison operator is "listed" or "not listed", the # sign must be used to separate the list values. For example, user1#user2#user3.

Error Message Customization

Messages returned for errors that may occur during policy execution can be customized. This allows developers to customize the error messages returned to clients in a corporate or understandable format.

Each policy can customize the messages returned when errors occur:

Note: In the policy definition interface, error codes and messages can be customized for that policy, as well as platform-wide error customization.

Delete Policy

A policy can be deleted if it is no longer used or if it has been configured incorrectly. Deletion is irreversible, so caution should be exercised.

If the policy is local, it is deleted from the API Proxy or API Proxy Group.

If it is a global policy, on the global policy page:

• By selecting Delete from the ⋮ menu at the end of the line in the list, or
• Or it can be deleted by clicking the [Delete] button on the policy detail page.

Additionally, if the policy is a global policy and is currently in use by one or more API Proxy/API Proxy Groups, the references used are displayed along with a "This policy is currently in use" warning. Upon the user's request to continue, the policy and the relevant references are deleted. The references are placed in a "redeploy required" status.

Instead of deleting, you may also consider deactivating.

Export/Import Policy

Policies can be exported for backup, migration, or sharing, or a previously exported policy can be re-imported. This process is used to maintain data integrity during version management, migration between test and production environments, or cross-team sharing.

Binding Policy to API

In this step, the user associates the policy they created with one or more APIs. Policies can be assigned either globally (applicable to all projects) or locally (for a specific API only). Additionally, multiple policies can be managed centrally by grouping them under a Policy Group.

For more detailed information on how to perform these operations, see the Message Flow and Policy Management page.

Best Practices

- Create policies for reusability.
- Prefer global policies when possible.
- Make error messages user-friendly.
- Avoid unnecessarily complicating policy conditions.
- Redeploy after changes.

Message Flow and Policy Management

For detailed information about the order in which policies are applied in the message flow, the operating logic at the API Proxy Group/API Proxy/Endpoint levels, and the visual flow diagram, see the Message Flow and Policy Management page.