This section describes the general features of the policies. For detailed information on any policy and how to configure it, please refer to the relevant policy's own page.

Entities used to define a set of rules, restrictions and transformations for the purposes of security, performance improvement and ease of use for messages coming to or returning from the API are generally referred to as policies.

The policy allows API behavior to be 'programmed' without the need for code development. It is designed to easily and reliably meet common management requirements for APIs.

It offers features such as security, rate limiting, conversion and brokerage capabilities and relieves you of the burden of writing code and maintaining these functions. Each policy works like a separate module that implements a specific function and whose behavior can be customized by configuration.

Policy Types

The policies offered on the Apinizer Platform can be roughly grouped functionally as follows:

Security Policies

Access Control Policies

Data Manipulation Policies

Threat Protection Policies

Other Policies

Policy Enforcement Points

Policies can be applied on 3 different points.

  1. On API Proxy Groups: When a policy is enforced on an API Proxy Group, this policy applies to all API Proxies in that group.
  2. On API Proxies: When a policy is applied on an API Proxy, this policy is applied for all methods/endpoints of that API Proxy.
  3. On methods/endpoints of API Proxies: The policy applied on a method/endpoint is only executed for that method/endpoint, it does not affect other method/endpoints.

For detailed information on the enforcement of policies on different points and the order of execution of these policies, see the Development Tab section.

Policy Usage Types

Policies can be Local or Global.

Local Policy

A local policy can only be created on the Development Tab of the API Proxy to which it is intended to be added and can only be used by this API Proxy. If the API Proxy is deleted, local policy is also deleted with it.

Global Policy

Global policies can be created independently of API Proxies from Global Policies interfaces or from within the Development Tab of an API Proxy. A global policy can be used by zero or more API Proxies. When an API Proxy is deleted, the global policies used by that API Proxy are not affected. However, any update to the global policy affects all API Proxies that use that policy.

Policy Structure

Policies are structurally the same except for the configuration information that differs in terms of the specific function they are defined for, and they contain some common data fields.

Common Data Fields

These data fields, which are common to all policies, are given in the table below.

NameIt does not appear in the interface as it is not needed for local policies. However, it is a required field for global policies and is used in policy selections so that the users can find the policies they are looking for. It must be unique within a project.
DescriptionIt is an optional, short explanation information about the policy. It is useful to enter it for global policies.


Sometimes it is desirable to decide whether to operate an added policy, for example, by looking at the existence of a parameter or the value of a header. Apinizer provides Conditions section for all policies so that users can define such requirements. Conditions can use logical operators such as AND, OR, NOT. The conditions are tested before the policy is executed, and if the conditions are not met, the policy will not be executed.

Error Message Customization

When executing any policy, an error message may be returned to the client for various reasons. Apinizer has predefined error codes and messages for each policy depending on the cause of the error. Users can customize these error codes or messages for any policy.
ActiveIndicates the status of the policy. By default, policies are created with the value Active. However, for any reason, they can be temporarily disabled by making the value of this field Passive.

Defining a Condition 

By adding conditions to the policy, it is ensured that it works only when the defined conditions are met. The image below shows an example condition where the selected policy will run only if the value of the status parameter is pending.

Error Message Customization

The HTTP Status Code, Error Code, and Error Message fields in the error messages are customizable. Error codes and messages can be customized for a policy in the policy definition interface, as well as error customization can be made across the platform.

The Customize Error Message fields are shown in the table below.


HTTP Status Code

It is the default HTTP status code. Its default value is set via the System Settings → Error Messages screen. 

Error Code

It is the default error code. Its default value is set via the System Settings → Error Messages screen. 

Original Message

It is the default error message. Its default value is set via the System Settings → Error Messages screen. 

Customized HTTP Status Code

It is the custom HTTP status code that will be returned for the error.

Customized Error Code

It is the custom error code that will be returned for the error.

Customized Error Message

It is the custom error message that will be returned for the error