Overview
What is its Purpose?
- Transform data on request or response according to business rules with action chains to make it consistent.
- Normalize content coming from different data sources to ensure integrity in API Proxy flow.
- Apply business logic only in specific endpoint flows with conditional rule execution.
- Keep sensitive fields that need to be masked or removed under control at policy level.
Working Principle
- Request Arrival: For each HTTP/HTTPS request arriving at the API Gateway, the source IP address of the request is identified.
- Policy Check: If the Business Rule policy is active, the system checks in the following order:
- Is a Condition defined? If so, is the condition met?
- Is the policy active (active=true)?
- Is a Variable being used or is Apinizer default?
- Action Chain Execution: Action list is evaluated sequentially; each action applies operators according to selected data type (numeric/string/temporal), extracts JWT claims if needed, or performs JSON/XML transformation.
- Decision Making:
- Match Found: All actions are applied; request’s payload, header, or variables are updated.
- No Match: Policy is skipped; request continues in flow with current state.
- Error Handling: Customizable HTTP status code and error message are returned for requests that do not comply with the policy rule.
Features and Capabilities
Basic Features
- Action Chain Management: Sequential operations are defined on variables in the request with action types like ADD, MODIFY, DELETE, STOP.
- Data Type-Based Operator Support: Different operators (e.g., SUBSTRING, ADD_TEMPORAL, MULTIPLY) can be selected for Numeric, String, and Temporal data types.
- Advanced Transformation Capability: JSON↔XML transformations, XSLT/JOLT-based manipulations, and URL encode/decode operations are performed within action scope.
- Active/Passive Status Control: Easily change the active or passive status of the policy (active/passive toggle). In passive mode, the policy is not applied but its configuration is preserved.
- Condition-Based Application: Determine when the policy will be applied by creating complex conditions with Query Builder (e.g., only for specific endpoints or header values).
Advanced Features
- JWT Claim Extraction: JWT contents can be retrieved to variables with EXTRACT_JWT_HEADER_CLAIM and EXTRACT_JWT_BODY_CLAIM operators.
- Variable Management Integration: Project variables can be selected as source and target, updated from dialog screen if needed.
- Transformation Profile Settings: Null, empty, and array behaviors in JSON2XML/XML2JSON transformations are managed with fine-tuning.
- Export/Import Feature: Export policy configuration as a ZIP file. Import to different environments (Development, Test, Production). Version control and backup capability.
- Policy Group and Proxy Group Support: Manage multiple policies within Policy Group. Bulk policy assignment to Proxy Groups. Centralized update and deploy operations.
- Deploy and Versioning: Deploy policy changes to live environment. See which API Proxies use it (Policy Usage). Proxy Group and Policy Group usage reports.
Usage Scenarios
| Scenario | Status | Solution (Policy Application) | Expected Behavior / Result |
|---|---|---|---|
| JWT Claim Enrichment | User role needs to be moved to header after authentication. | Action List: sourceDataType=STRING, operator=EXTRACT_JWT_BODY_CLAIM, targetVar=X-User-Role. | Role value is added to header, backend does not make additional query. |
| Credit Card Masking | Full card number is falling into logs. | Action List: operator=MASK, maskFrom=6, maskTo=12. | Card number is masked, sensitive data is protected. |
| Date Normalization | There are endpoints receiving dates in different formats. | Action List: sourceDataType=TEMPORAL, operator=ADD_TEMPORAL (0 days), format=yyyy-MM-dd. | All dates are converted to standard format. |
| XML → JSON Transformation | Legacy service returns XML, microservice expects JSON. | Action List: operator=TRANSFORM, transformationContentType=XML2JSON, unwrapElement=true. | Response is rewritten in JSON format |
| Value Validation and Stop | Request should not continue with incorrect value. | First action: condition check, second action: actionType=STOP, custom error message. | Flow stops on rule violation and custom error is returned. |
| Multiple Variable Merging | Data from different headers will be collected and new payload field will be created. | Action List: operator=CONCAT collects source header values, targetValSource=VARIABLE. | New field is created, downstream service does not perform complex operation. |
Configuring Policy Parameters
In this section, you can create a new Business Rule policy or configure existing policy parameters to define access rules.Creating a New Business Rule Policy

Configuration Steps
| Step | Description / Operation |
|---|---|
| Step 1: Go to Creation Page | - Go to Development → Global Settings → Global Policies → Business Rule from the left menu. - Click the [+ Create] button at the top right. |
| Step 2: Enter Basic Information | Policy Status: Shows Active/Passive status. New policies are active by default. Name (Required): Example: Production_BusinessRule- Enter a unique name, does not start with space. - System automatically checks: Green checkmark: available Red X: existing name. Description: Example: “Transforms variables in request flow according to business rules in Prod environment.” - Max. 1000 characters. - Explain the purpose of the policy. |
| Step 3: Define Action Chain | - Press Add button in Action List table. - Select Action Type (ADD/MODIFY/DELETE/STOP). - Determine Source Data Type (NUMERIC/STRING/TEMPORAL). - Select operator (e.g., SUBSTRING, ADD_TEMPORAL, EXTRACT_JWT_BODY_CLAIM) and fill its parameters. |
| Step 4: Source and Target Selection (If Any) | - Enter Source Variable or literal value for source value. - Use Target Variable or Target Value in target. - Open Variable dialogs to create and bind project variables. |
| Step 5: Define Condition (Optional) | - Go to Condition tab. - Conditions determine when the policy will be active. Examples: - Environment-based: Header = X-Environment, Operator = Equals, Value = production- API Key-based: Header = X-API-Key, Starts With = PROD-- Endpoint-based: Path = /api/admin/*If no condition is defined, policy is always active For details, you can refer to: Conditions |
| Step 6: Customize Error Message (Optional) | - Go to Error Message Customization tab. - Customize the message to be returned when access is denied. Default: { "statusCode": 403, "message": "[Default error message]" }Custom: { "statusCode": 403, "errorCode": "[CUSTOM_ERROR_CODE]", "message": "[Custom message]" } |
| Step 7: Save | - Click the [Save] button at the top right. Checklist: - Unique name - Required fields filled - At least one action exists Result: - Policy is added to the list. - Can be connected to APIs. - If global policy, automatically applied. |
Deleting the Policy
For deletion steps of this policy and operations to be applied when in use, you can refer to the Remove Policy from Flow section on the Policy Management page.Exporting/Importing the Policy
For export (Export) and import (Import) steps of this policy, you can refer to the Export/Import page.Connecting the Policy to API
For the process of how this policy will be connected to APIs, you can refer to the Connect Policy to API section on the Policy Management page.Advanced Features
| Feature | Description and Usage Steps |
|---|---|
| JWT Claim Extraction Chain | - Select MODIFY as Action Type. - Determine Source Data Type = STRING, Operator = EXTRACT_JWT_BODY_CLAIM. - Enter desired claim in claimJsonPath field, select target variable and save. |
| XML2JSON Transformation Profile | - Select TRANSFORM operator and set transformationContentType=XML2JSON.- Mark xmlToJsonIgnoreNull and xmlToJsonIgnoreEmpty options as needed.- Verify that result JSON will be transferred to target variable. |
| Conditional STOP Action | - Define desired rule condition in Query Builder. - Add STOP type action to Action List and select custom error message. - Test that STOP action activates when previous actions meet the condition. |
Best Practices
Things to Do and Best Practices
| Category | Description / Recommendations |
|---|---|
| Action Chain Design | Bad: Combining all business rules in a single action. Good: Defining each rule as a separate action. Best: Ordering logically grouped actions and dividing with STOP action if needed. |
| Variable Management | Bad: Working with literal values and not using variables. Good: Reading common values from project variables. Best: Creating versioned variables with variable dialog and standardizing targets. |
| Error Message Structure | Bad: Leaving general error message. Good: Writing a directive message to user. Best: Customizing error message with code, message, and debug-friendly context. |
| Condition Management | Bad: Leaving conditions empty and running policy on every request. Good: Filtering based on endpoint or header. Best: Using Query Builder by combining environment, user segment, and method information. |
| Cross-Environment Transfer | Bad: Directly editing in Production environment. Good: Editing and exporting in test environment. Best: Performing version control with ZIP export-import and deploying changes through pipeline. |
Security Best Practices
| Security Area | Description / Warnings |
|---|---|
| JWT Claim Management | Only retrieve needed fields when extracting claims, mask unauthorized information. |
| Data Masking | Shorten personal data with MASK or SUBSTRING, prevent sensitive data from falling into logs. |
| Error Message Control | Do not put internal system details in error messages in production. Write general but directive messages. |
| Global Policy Updates | Review usage list before updating global policy, localize if needed. |
| Variable Authorization | Select only variables accessed by authorized users as target variable, check permissions. |
Things to Avoid
| Category | Description / Warnings |
|---|---|
| Empty Action List | Why to avoid: No operation is performed even if policy is saved, expected workflow is broken. Alternative: Define at least one action and check validation icon. |
| Wrong Data Type Selection | Why to avoid: Operator gives error or unexpected result occurs. Alternative: Analyze source data, correctly select Numeric/String/Temporal type. |
| Uncontrolled STOP Usage | Why to avoid: All requests may be accidentally stopped, service interruption occurs. Alternative: Apply STOP action only after condition filter. |
| Directly Deleting Global Policy | Why to avoid: Multiple APIs may become unprotected. Alternative: First deactivate or replace with local policy then delete. |
Performance Tips
| Criterion | Recommendation / Impact |
|---|---|
| Action Order | Recommendation: Put frequently used and light actions at the beginning. Impact: Flow can be terminated before unnecessary heavy operations. |
| Transformation Operators | Recommendation: Use TRANSFORM operations minimally, open separate policy if needed. Impact: CPU load decreases, latency drops. |
| Condition Filters | Recommendation: Write narrow-scope conditions with Query Builder. Impact: Policy works only when needed, throughput increases. |
| Variable Sharing | Recommendation: Take frequently used values to project variables. Impact: Literal operations are not performed repeatedly within action. |
| JWT Operations | Recommendation: Limit JWT claim extraction to only requests that need it. Impact: Unnecessary parsing cost decreases. |
Frequently Asked Questions (FAQ)
| Category | Question | Answer |
|---|---|---|
| General | What types of data does this policy work on? | Works with Numeric, String, and Temporal data types; operator selection is automatically filtered according to data type. |
| General | Should I create global or local? | Global is recommended if multiple API Proxies need the same rule, local if specific to a single API. |
| Technical | What does STOP action do? | Action chain stops at this point, customized error message is returned and flow ends. |
| Technical | How is target value set when extracting JWT claim? | Operator automatically makes target value source VARIABLE; you need to select a project variable. |
| Usage | Why am I getting a warning if Action List is empty? | At least one action is required for policy to work; warning icon indicates this. |
| Usage | How do I control array fields in XML2JSON transformation? | Enter XPaths that should be arrays in xmlToJsonArrayPathList field to get correct type in transformation. |

