Skip to main content
Tracing enables you to monitor and analyze your API Proxy message processing flow in real-time. Trace operations are performed on an API Proxy basis and are activated separately for each API Proxy. This module is particularly used for:
  • Understanding how policies work
  • Detecting performance issues
  • Debugging
  • Examining request/response flow
  • Validating transformations

API Proxy-Based Trace

You can start a separate trace session for each API Proxy

Detailed Tracking

You can track each policy’s execution step by step and view log records

Performance Analysis

You can analyze timing metrics and detect bottlenecks

Debugging

You can easily detect errors and perform root cause analysis
Trace operations are performed on an API Proxy basis. For detailed application steps, you can refer to the Step-by-Step Tracking page.

​
Starting Trace Mode

Trace mode is started separately for each API Proxy. You can activate trace mode from the API Proxy’s own page.

​
Prerequisites

Before starting trace mode:
1

API Proxy Must Be Loaded

The API Proxy you want to track must be loaded into at least one Environment
2

Go to API Proxy Page

Go to the detail page of the API Proxy you want to trace
3

Make Environment Selection

Select the Environment for which trace mode will be opened from the Environments where the API Proxy is loaded
4

Click Start Button

Activate trace mode by clicking the Start button
Activating Trace Mode
With Custom Query from the filter field next to environment selection, you can specifically trace only desired data.
When trace mode is activated:
  • Log record content is expanded to allow detailed examination
  • Log records are written to MongoDB configuration database
  • Detailed log records are created for all executed policies
  • This continues to be stored until the mode is stopped or automatically closed by the platform after 5 minutes

​
Trace Records

After trace mode is activated, requests coming to the API Proxy are automatically tracked and detailed records are created. Trace Log Records
Log records being displayed are not automatically updated. Use the Refresh Logs button to see new records.
Each log record shown in the table belongs to the request coming from the client to this API Proxy and the response message given to that request.
Since the log record of API Call Policy is kept separately, double logs appear for the same request. The first is the before and after state of the message in the main flow, and the second is the request and response message coming out of the API Call.

​
Trace List

The following information is displayed for each record in the trace list:
InformationDescription
TimestampDate and time when the request arrived
MethodHTTP method (GET, POST, PUT, DELETE, etc.)
Path / EndpointRequest path and endpoint name
Status CodeResponse status code (200, 404, 500, etc.)
DurationTotal processing time (ms)
PoliciesNumber of policies executed
Correlation IDRequest-specific correlation ID
When API Call Policy is used, double log records appear for the same request:
  1. Before and after state of the message in the main flow
  2. Request and response message coming out of the API Call

​
Trace Operations

The following operations can be performed for each trace record:
The first button at the end of the row of the request message to be examined opens a window that displays the log records of that message.Detailed View ButtonIn the opened window, logs are divided into sections related to message flow. When the name of the section to be examined is clicked, log records related to that area are displayed. By default, the Overview section is open.Detailed View Dialog

​
Tracking Policy Flow

Click the Select button to view the detailed log records kept by Apinizer for policies executed for the API Proxy while in step-by-step tracking mode. Selection When this button is clicked, a new section opens below the table containing log records. This section shows all policies executed for the selected message, including those coming from API Proxy Group if any, in the order they were executed. Small icons are located next to each policy and Backend API to show whether that step was executed successfully. Thus, if the message flow did not occur as expected, it is visible which policy caused the problem.
Situation where all policies are executed successfully:Successful Policy Flow

​
Policy Execution Details

Policies executed first when a request arrives:
  • Policy Name: Name of the executed policy
  • Execution Time: Policy execution time (ms)
  • Status: Success / Failure status
  • Changes: Changes made by the policy to the message (header, body, variable changes)
Examples: Authentication, rate limiting, IP control
Routing step to Backend API:
  • Selected Upstream: Selected upstream target
  • Load Balancing Decision: Load balancing algorithm decision
  • Connection Time: Connection time to backend (ms)
  • Backend Response Time: Backend response time (ms)
  • Retry/Failover: Retry or failover status
Policies executed after response comes from backend:
  • Policy Name: Name of the executed policy
  • Execution Time: Policy execution time (ms)
  • Status: Success / Failure status
  • Changes: Changes made to the response message
Examples: Response transformation, cache writing, logging
Policies executed in case of error:
  • Error Type: Error type (authentication, routing, policy, etc.)
  • Error Message: Error message
  • Handler Policies: Executed error handler policies
  • Final Response: Final response returned to client
Fault Handler only runs when an error occurs and allows you to customize the error response.

​
Detailed Log Records

The section displayed when a log record is selected presents a summary of whether the message flow was successful and, if it failed, at which point it occurred. Detailed Log Records The following links can be used to view detailed log records:
Detailed log records allow you to track each step of the message flow and quickly identify the source of problems.
Client is a link. When clicked, a window opens where details of messages going from and returning to the client can be viewed.Details of the HTTP message sent by the client:Client Log 1Details of the message sent from client to API Proxy:Client Log 2Details of the message returned from API Proxy to client:Client Log 3
When a policy icon in region 2 is clicked or the arrow next to the relevant policy in region 4 is clicked, log records showing the message content coming to and going from that policy are opened.Policy Log Records
API is a link. When clicked, a window opens where details of messages coming to and returning from the Backend API can be viewed.Details of the message coming from API Proxy:Backend API Log 1Backend API routing details (for routing options, you can refer to the HTTP Routing page):Backend API Log 2Details of the message returned from Backend API to API Proxy:Backend API Log 3

​
Request/Response Comparison

Trace mode shows how the message changes along the flow:

Before/After

You can compare the before and after state of the message for each policy

Transformation Analysis

You can see the effect of transformation policies

Header Changes

You can see added, modified, or deleted headers

Body Changes

You can see JSON/XML transformations and content changes

​
Performance Analysis

Trace mode provides detailed timing metrics to detect performance issues.

​
Timing Metrics

The following metrics are displayed for each trace record:
MetricDescription
Total DurationTotal entry-exit time of the request (ms)
Pre-flow DurationTotal execution time of pre-flow policies
Route DurationConnection to backend and response receiving time
Backend DurationBackend API response time (net)
Post-flow DurationTotal execution time of post-flow policies
Gateway OverheadTime added by Apinizer Gateway (Total - Backend)
If Gateway Overhead is high, policy optimization can be done. If Backend Duration is high, backend API should be optimized.

​
Policy Performance Analysis

To analyze policy performance:

Slowest Policies

You can identify and optimize policies taking the longest time

Policy Count

You can see the total number of policies executed, remove unnecessary policies

Average Policy Duration

You can monitor the average execution time of each policy

Policy Execution Order

You can improve performance by changing the order of policies
Optimization Recommendations:
  • Cache Policy: Use cache to reduce backend calls
  • Conditional Flow: Conditionally skip unnecessary policies
  • Script Optimization: Optimize slow operations in script policies
  • Transformation: Remove unnecessary transformations

​
Backend Performance Metrics

To monitor backend API performance:
MetricDescription
Connection TimeTCP connection time to backend server
SSL Handshake TimeSSL handshake time for HTTPS connection
Response TimeBackend response generation time
Total Backend TimeConnection + Response total time
Backend StatusSuccess status of backend call
Retry/Failover CountNumber of retries or failovers performed
High Connection Time indicates that the backend server is slow or has network issues. High Response Time indicates that the backend API needs to be optimized.

​
Use Cases

​
Scenario 1: Performance Issue Detection

Situation: Response times of an API Proxy are higher than expected.
1

Start Trace

Activate trace mode from the API Proxy page
2

Examine Slow Requests

Find slow requests (e.g., >1000ms) in trace records
3

Examine Policy Flow

View policy flow with Select button and identify slowest policies
4

Detect Bottlenecks

  • Is backend API slow? → Backend should be optimized
  • Are policies slow? → Script/transformation should be optimized
  • Is database query slow? → Cache can be used
5

Perform Optimization

Fix detected issues and test again with trace

​
Scenario 2: Debugging

Situation: Some requests return 500 error and the cause is unknown.
1

Start Trace

Activate trace mode from the API Proxy page
2

Find Failed Requests

Find 5xx errors in trace records
3

Find Policy Where Error Occurred

View policy flow with Select button and find the red-marked policy
4

Examine Policy Details

  • Examine the message coming to the policy (Before)
  • Read the error message
  • Examine detailed log records
5

Perform Root Cause Analysis

  • Is data format wrong?
  • Is header missing?
  • Is it a script error?
  • Is backend unreachable?
6

Fix and Test

Fix the issue and test again with trace

​
Scenario 3: Transformation Validation

Situation: Checking if JSON to XML transformation works correctly.
1

Start Trace

Activate trace mode from the API Proxy page
2

Send Test Request

Send a sample JSON request from Test Console
3

Select Transformation Policy

View policy flow with Select button and click on transformation policy
4

Compare Before/After

  • Before: Incoming JSON message
  • After: Converted XML message
  • Check if the transformation is correct
5

Check Message Going to Backend

Verify in Backend API log records that the outgoing message is in XML format and correct

​
Scenario 4: Conditional Flow Testing

Situation: Testing if conditional policies work correctly.
1

Start Trace

Activate trace mode from the API Proxy page
2

Send Requests for Different Conditions

  • Request for premium user
  • Request for normal user
  • Request for guest
3

Examine Trace for Each Request

View policy flow with Select button and see which policies ran
4

Check Condition Evaluation

  • What was the condition expression?
  • What was the evaluation result?
  • Did the correct policies run?
5

Fix Conditions if Necessary

Fix incorrect conditions and test again with trace

​
Best Practices

​
Trace Usage

Use Frequently in Development Environment

  • Trace continuously during development
  • Always test with trace when adding new policies
  • Validate API changes with trace

Be Careful in Production

  • Activate trace in production only when necessary
  • Trace automatically closes after 5 minutes
  • Consider performance impact

Use Custom Query

  • Filter with Custom Query from the filter field next to environment selection
  • Trace only relevant endpoints
  • Minimize unnecessary trace records

Use on API Proxy Basis

  • Start trace separately for each API Proxy
  • Activate trace mode from the relevant API Proxy’s page
  • Trace records are stored in MongoDB

​
Performance Monitoring

Create Performance Baseline:
  • Measure average response time of API under normal conditions
  • Record average execution time of each policy
  • Monitor deviations from baseline and set alarms
Regular Monitoring:
  • Run performance trace once a week
  • Perform trend analyses
  • Detect slowdowns early
Optimization Cycle:
  1. Detect bottlenecks with trace
  2. Optimize
  3. Validate improvement with trace
  4. Document results

​
Debugging

Repeatable Test Scenarios:
  • Prepare test scenarios before starting trace
  • Get consistent results using the same test data
  • Test edge cases
Systematic Approach:
  1. Isolate the problem (which endpoint, under which condition?)
  2. Collect detailed information with trace
  3. Perform root cause analysis
  4. Fix
  5. Validate with trace
  6. Document the process
Before/After Comparison:
  • Compare input/output messages for each policy
  • Detect unexpected changes
  • Check transformation correctness

Step-by-Step Tracking

API Proxy-based trace operations

Test Console

API test and debug console

Policy Management

Managing and configuring policies

API Traffic Log Settings

Configuring log record settings

Message Processing and Policy Application

Information about message flow and policy execution

Conditional Policy Execution

Detailed information about conditional flow