Data Redaction

You can conditionally modify or delete header, parameter, or body fields or values in messages returned from backend API, and provide response customization according to different user types

This document explains the detailed usage of a specific policy. If you are using Apinizer policy structure for the first time or want to learn the general working principles of policies, we recommend reading the What is Policy? page first.

Overview

What is its Purpose?

• Conditionally modifies or deletes header, parameter, or body fields or values in messages returned from backend API.
• Eliminates the need to create separate APIs for each user type by providing response customization according to different user types.
• Ensures data privacy by masking or removing sensitive information in message content.
• Performs flexible data manipulation with condition-based actions, using various operators for numeric, text, and time data types.

Working Principle

1. Response Reception: Message returned from backend API reaches the API Gateway.
2. Policy Check: If the Data Redaction 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)?
   • Are rule sets defined?
3. Rule Evaluation: For each rule set:
   • Variable existence or variable value check is performed.
   • If the condition is met, defined actions are applied in order.
4. Action Application:
   • Modify: The value of the selected field is modified using an operator according to the data type.
   • Delete: The selected field or value is removed from the message.
5. Result: Customized response is transmitted to the client.

Differences from Business Rule Policy

Since data transformation is performed within the message, it can be confused with the Business Rule policy. The differences between these two policies;

• While Business Rule policy is added to both request and response pipelines, Data Redaction policy is only added to the response pipeline.
• While direct actions (Add, Modify, Delete, Stop Flow) can be defined in Business Rule policy, actions (Modify, Delete) are defined in Data Redaction policy when a specific field or field value is encountered.

Features and Capabilities

Basic Features

• Conditional Data Manipulation: Dynamically modifies or deletes message content based on variable existence or variable value.
• Multiple Data Type Support: Performs operations with various operators on numeric, text, and time data types.
• Flexible Action Definition: Multiple actions can be added to a rule, actions are applied in order.
• Variable-Based Access: Provides access to header, parameter, or body fields of the message with variables.
• Active/Passive Status Control: Easily change the active or passive status of the policy (active/passive toggle). In passive state, 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

• Advanced Text Operations: Text manipulation operators such as Base64 encode/decode, mask, format, substring, replace, transform.
• Mathematical Operations: Addition, subtraction, multiplication, division, modulo, exponentiation operations on numeric values.
• Time Manipulation: Addition or subtraction operations on time values.
• XSLT and JOLT Transformations: Can perform XML and JSON transformations with Transform operator.
• 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 deployment 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	Situation	Solution (Policy Application)	Expected Behavior / Result
Sensitive Information Masking	Sensitive information such as credit card number, phone number in API response needs to be hidden	Specific characters are replaced with * using Mask operator.	Sensitive information is transmitted to client in masked form.
Data Filtering by User Type	Different data sets need to be shown to different user types	Condition is defined according to user type, relevant fields are deleted or modified.	Each user type sees data within their authorization.
Price Information Customization	Different pricing needs to be shown to different customer segments	Price field is modified according to variable value, discount rates are applied.	Customized prices are shown according to customer segment.
Header Clearing	Some headers from backend should not be transmitted to client	Relevant header fields are removed with delete action.	Specified headers are removed from response.
Data Transformation	Format of data from backend needs to be changed	XSLT or JOLT transformation is applied with Transform operator.	Data is transformed to desired format and transmitted.
Base64 Encoding/Decoding	Base64 encoded data in message content needs to be processed	Encode Base64 or Decode Base64 operator is used.	Data is encoded or decoded.
Time Information Manipulation	Time information in response needs to be adjusted according to different time zones	Addition or subtraction operation is performed on time type.	Time information is adjusted according to desired time zone.
Standardization in API Proxy Group (optional)	Apply the same data manipulation rule on multiple API Proxies	Policy is added to Policy Group, linked to Proxy Group, centralized deployment is performed.	All linked API Proxy instances use the same Data Redaction rule.

Configuring Policy Parameters

At this step, users can create a new policy or configure existing policy parameters to define data manipulation rules. The defined parameters directly affect how the policy works (e.g., which fields will be modified, under which conditions actions will be performed, conditional activations, etc.). This way, the policy can be customized according to organization-specific requirements and managed centrally.

Creating a New Data Redaction Policy

Configuration Steps

Step	Description / Operation
Step 1: Going to Creation Page	- Go to Development → Global Settings → Global Policies → Redaction section from the left menu. - Click the [+ Create] button at the top right.
Step 2: Entering Basic Information	Policy Status: Shows Active/Passive status. New policies are active by default. Name (Required): Example: Production_DataRedaction - Enter a unique name, it cannot start with a space. - System automatically checks. Green checkmark: available. Red cross: existing name. Description: Example: “Sensitive information masking rule for production service” - Max. 1000 characters. - Explain the purpose of the policy.
Step 3: Creating Rule Set	Rule Sets: - Click the [+ Add Rule Set] button to add a new rule. - Follow the steps below for each rule set.
Step 4: Rule Configuration	Redact By: - Existence of a variable: Specifies which element (header, parameter, body) of the message to check. - Value of a variable: Specifies what values the element should have. Variable for rule set: Select a variable to access the element in the message. Values: If variable value is selected, enter comma-separated values.
Step 5: Defining Action	Action Definitions: - Click the [+ Add Action] button to add an action. - Select one of Modify or Delete actions. - Actions are applied in order, you can change the order.
Step 6: Configuring Modify Action	Modify Variable: Select a variable to specify which element to modify. Variable Data Type: Select Numeric, Text, or Time. Operator: Select the appropriate operator according to data type (e.g., Replace, Mask, Addition, etc.). Target Value Source Type: - Specify the Value: Enter value manually. - Use a Variable: Get value from variable. Value or Variable for target value source: Fill in the relevant field.
Step 7: Configuring Delete Action	Delete: Select a variable to specify which element to delete. This action does not error if not found, continues with other operations.
Step 8: Defining Condition (Optional)	- Go to the Condition tab. - Conditions determine when the policy will be active. Examples: - Environment-based: Header = X-Environment, Operator = Equals, Value = production - Endpoint-based: Path = /api/admin/* - User type-based: Header = X-User-Type, Operator = Equals, Value = premium If no condition is defined, the policy is always active.
Step 9: Customizing Error Message (Optional)	- Go to the Error Message Customization tab. - Customize the message to be returned when action fails. Default: { "statusCode": 500, "message": "[Default error message]" } Custom: { "statusCode": 500, "errorCode": "[CUSTOM_ERROR_CODE]", "message": "[Custom message]" }
Step 10: Saving	- Click the [Save] button at the top right. Checklist: Unique name. Required fields filled. At least one rule set defined. Result: - Policy is added to the list. - Can be linked to APIs. - If it’s a global policy, it is automatically applied.

Rule and Action Details

Creating a Rule

A rule is a criterion that specifies what the response will be redacted by. An action is the editing operation to be performed on the message when this criterion is encountered.

Multiple actions can be added to a rule. Message customization is performed according to the given action order. Additionally, there can be multiple rules in the policy.

The fields used for rule configuration are shown in the table below.

Field	Description
Redact By	The redaction operation can be performed according to different values selected from within the sent message. Existence of a variable: Specifies which element (header, parameter, body) of the message to check when applying the rule. Value of a variable: Specifies what values the element in the message should have when applying the rule.
Variable for rule set	A variable is selected to access the element in the message.
Values	If redaction management is selected as Variable value, this field becomes active. The values that should be in the field selected with the variable should be written separated by commas.
Action Definitions	Actions that can be applied are listed in order of execution in this table, or new ones can be defined.

Creating an Action

2 types of actions can be selected:

• Modify: The value of an existing field in the header, parameter, or body of the request/response is modified.
• Delete: The value of an existing field or the entire field in the header, parameter, or body of the request/response is deleted.

Modify Action

Used to modify the value in the header, parameter, or body of the message.

When this action is selected, it is assumed that the value to be added exists in the message, and if it is not found, the policy errors. This should be considered in the condition part of the rule.

The fields used for modify action configuration are shown in the table below.

Field	Description
Modify Variable	A variable is selected to specify which element of the message to modify.
Variable Data Type	Specifies what data type the variable value is. Details are in the table below.
Operator	Selects which operation will be applied in the data type. Details are in the table below.
Target Value Source Type	Selects where the value source will be taken from. Specify the Value: When this option is selected, the value of the source is entered manually. Use a Variable: With this option, the value is created from a variable.
Value	The value of the element to be modified is written.
Variable for target value source	The value of the element to be modified is selected from a variable.

Data Type and Operators

The data type (Variable Data Type) and operations (Operator) for these data types can be:

Data Type	Action	Description
Numeric	Addition	Modifies by adding the target value to the value to be modified.
	Subtraction	Modifies by subtracting the target value from the value to be modified.
	Multiplication	Modifies by multiplying the value to be modified with the target value.
	Division	Modifies by dividing the value to be modified by the target value.
	Modulo	Modifies by taking the modulo of the value to be modified with respect to the target value.
	Exponentiation	Modifies by taking the exponentiation of the value to be modified to the power of the target value.
Text	Concat	Modifies by appending the target value to the end of the value to be modified.
	Decode Base64	Modifies by subjecting the value to be modified to Base64 decryption operation.
	Encode Base64	Modifies by subjecting the value to be modified to Base64 encryption operation.
	Format	Modifies by masking the value with the properties specified in the javax.swing.text.MaskFormatter class.
	Insert	Modifies by writing the target value starting from the specified text index of the value to be modified.
	Mask	Modifies by masking the entire value to be modified or the range specified with text indices.
	Replace First	Modifies by replacing the first match of the specified replacement data in the value to be modified with the target value.
	Replace	Modifies by replacing all matches of the specified replacement data in the value to be modified with the target value.
	Replace With	Modifies by completely replacing the value to be modified with the target value.
	Substring	Modifies by deleting fields outside the specified text indices part of the value to be modified.
	Transform	Modifies by subjecting the value to be modified to XSLT or JOLT operation.
	Trim	Removes leading and trailing spaces of the value to be modified.
Time	Addition	Adds the specified time unit and amount to the value to be modified.
	Subtraction	Subtracts the specified time unit and amount from the value to be modified.

Delete Action

Used to delete the value in the header, parameter, or body of the message.

When this action is selected, it is assumed that the value to be deleted exists in the message, and if it is not found, the policy does not error, continues with other operations.

Where in the message will be deleted is specified with a variable.

For the description of Conditions and Error Message Customization panels, you can review the Conditions and Error Message Customization sections on the What is Policy? page.

For a complete guide on all layers, priority order and scenario examples of the error message configuration system, see the Error Message Configuration Guide page.

Deleting the Policy

For the deletion steps of this policy and the operations to be applied when it is in use, you can refer to the Removing Policy from Flow section on the Policy Management page.

Exporting/Importing the Policy

For the export and import steps of this policy, you can refer to the Export/Import page.

Linking the Policy to API

For the process of how this policy will be linked to APIs, you can refer to the Linking Policy to API section on the Policy Management page.

Advanced Features

Feature	Description and Steps
XSLT and JOLT Transformations	- You can transform XML and JSON data with Transform operator. - You can perform complex transformations using XSLT templates or JOLT spec files. - Transformation templates can be entered from variables or manually.
Conditional Masking	- You can mask specific parts of sensitive information with Mask operator. - You can specify the masking range using text indices. - You can mask formatted data such as phone numbers, credit cards with Format operator.
Multiple Rule Management	- You can create separate rules for different scenarios by defining multiple rule sets. - Each rule set works independently and applies its own actions. - There is no priority order between rule sets, all rules are evaluated.
Variable-Based Dynamic Values	- You can make dynamic value assignments by using variables as value source. - You can perform operations by taking values from other fields in the request or response. - You can provide centralized value management by using project variables.

Best Practices

Things to Do and Best Practices

Category	Description / Recommendations
Rule Design	Bad: Trying to modify all fields in a single rule. Good: Creating separate rule sets by grouping related fields logically. Best: Defining special rule sets for each user type or scenario, clearly determining conditions.
Action Ordering	Bad: Ordering actions randomly. Good: Organizing actions according to logical order (modify first, then delete). Best: Ensuring actions do not affect each other, verifying with test scenarios.
Variable Management	Bad: Using different variables in each rule, creating inconsistency. Good: Using standard variable sets, keeping variable naming consistent. Best: Managing project variables centrally, documenting.
Condition Usage	Bad: Applying policy to all requests without defining conditions. Good: Avoiding unnecessary processing load by defining basic conditions. Best: Optimizing complex conditions with Query Builder, performing performance tests.
Error Management	Bad: Leaving error messages as default, not providing meaningful information to users. Good: Defining custom error messages, adding error codes. Best: Thinking about error scenarios in advance, testing, determining logging strategy.
Policy Lifecycle	Bad: Making production changes directly in live. Good: Localizing and testing the same policy in test environment. Best: Creating versions with Export/Import and monitoring usage reports after Deploy.

Security Best Practices

Security Area	Description / Warnings
Sensitive Information Masking	Always mask sensitive information such as credit card numbers, phone numbers, emails; preserve data integrity by using mask instead of complete deletion.
Variable Validation	Do not apply actions without variable existence check; add error management for values that cannot be found.
Action Security	Use delete actions carefully; clearly determine conditions before deleting critical fields, test.
Performance Optimization	Minimize complex Transform operations; optimize XSLT/JOLT templates, avoid unnecessary processing load.
Logging Strategy	Log masking or deletion operations but do not write sensitive information to logs; perform secure logging for audit trail.

Things to Avoid

Category	Description / Warnings
Wrong Data Type Selection	Why avoid: Applying numeric operator to text value produces errors or unexpected results. Alternative: Verify the data type of the variable value in advance, select appropriate operator.
Missing Condition Definition	Why avoid: Applying policy to all responses without defining conditions leads to performance problems. Alternative: Always define conditions, policy should be active only in necessary situations.
Variable Access Errors	Why avoid: Trying to access non-existent variables causes policy errors. Alternative: Perform variable existence check, add error management.
Deploying Global Changes Directly	Why avoid: Multiple API Proxies are affected at the same time, service interruption may occur. Alternative: First localize and test, then update the global policy.

Performance Tips

Criterion	Recommendation / Impact
Number of Rules	Recommendation: Reduce unnecessary rule sets, combine similar rules. Impact: Policy evaluation time shortens, CPU load decreases.
Action Complexity	Recommendation: Minimize complex Transform operations, prefer simple operators. Impact: Processing time shortens, memory usage decreases.
Condition Optimization	Recommendation: Keep conditions simple, break complex conditions into parts. Impact: Condition evaluation speeds up, early exit is provided.
Variable Access	Recommendation: Cache frequently used variables, avoid unnecessary variable access. Impact: Variable resolution time shortens, performance increases.

Frequently Asked Questions (FAQ)

Category	Question	Answer
General	In which scenarios should Data Redaction policy be preferred?	It can be used in all situations where the content of messages returned from backend API needs to be modified or filtered according to user type, condition, or security requirements.
General	What is the difference between Business Rule policy and Data Redaction policy?	Business Rule policy works on both request and response pipelines and direct actions can be defined. Data Redaction policy only works on the response pipeline and conditional actions are defined.
Technical	What happens if Modify action is applied to a value that cannot be found?	Policy errors and response is not transmitted. Variable existence check should be performed in the rule condition to prevent this situation.
Technical	What happens if Delete action is applied to a value that cannot be found?	Policy does not error, continues with other operations. This behavior ensures safe operation of delete action.
Usage	Can multiple actions be added to a rule?	Yes, multiple actions can be added to a rule. Actions are applied in the order they are defined.
Usage	What transformations can be performed with Transform operator?	XML transformations with XSLT templates or JSON transformations with JOLT spec files can be performed.
Usage	How is Mask operator used?	With Mask operator, the entire text value or the specified index range is replaced with masking character (usually *).