API event record field reference

The backend_method field identifies the HTTP method that DataPower uses when it calls the backend service. The value can be GET, POST, PUT, DELETE, PATCH, or another supported HTTP method.

Purpose:

Example use case:

If your API accepts a POST request but the backend expects a GET, this field shows the actual method sent to the backend. This helps you detect policy configuration issues that modify or override the method.

{
  "backend_method": "POST"
}

Contains the full request payload sent from the API Gateway to the backend service.

Security considerations:

This field may include sensitive information. Ensure that analytics storage is protected with proper access controls, and apply data‑masking rules where appropriate to avoid exposure of confidential data.

Example use case:

If the backend service returns an error indicating missing or malformed fields, reviewing backend_request_body allows you to confirm exactly what the gateway transmitted. This helps determine whether the issue originates from the client request or from transformation logic within the gateway.

{
  "backend_request_body": "{\"customerId\":\"12345\",\"orderAmount\":99.99,\"currency\":\"USD\"}"
}
``

All HTTP headers that the API Gateway sends to the backend service. This list includes original headers from the client request and any headers that policies add or modify.

Requirements:

This field is available only when header logging is enabled.

Example use case:

If the backend service returns authentication errors, reviewing backend_request_headers shows whether the Authorization header was present and correctly set.

{
  "backend_request_headers": [
    {
      "Content-Type": "application/json"
    },
    {
      "Authorization": "Bearer eyJhbGciOiJIUzI1NiIs..."
    },
    {
      "X-IBM-Client-Id": "abc123"
    },
    {
      "Accept": "application/json"
    },
    {
      "User-Agent": "IBM-APIConnect/10.0.8"
    }
  ]
}

The complete response payload that the backend service returns to the API Gateway before any transformations are applied.

Requirement:

This field is available only when payload logging is enabled.

Example use case:

If clients report receiving incorrect or unexpected data, compare backend_response_body with the final response that the gateway returns. This comparison helps determine whether the backend produced the incorrect data or whether gateway transformations introduced the issue.

{
  "backend_response_body": "{\"orderId\":\"ORD-789\",\"status\":\"confirmed\",\"timestamp\":\"2026-02-18T16:30:00Z\"}"
}
``

All HTTP headers that the backend service returns to the API Gateway.

Requirement:

This field is available only when header logging is enabled.

Example use case:

When investigating caching behavior, reviewing backend_response_headers shows the actual Cache-Control directives from the backend. This comparison helps determine whether caching issues originate in the backend or are introduced by gateway policies.

{
  "backend_response_headers": [
    {
      "Content-Type": "application/json"
    },
    {
      "Cache-Control": "no-cache, no-store, must-revalidate"
    },
    {
      "X-RateLimit-Remaining": "95"
    },
    {
      "X-Response-Time": "45ms"
    }
  ]
}

The HTTP status code returned by the backend service.

Example use case:

When diagnosing API failures, compare

When investigating caching behavior, reviewing backend_response_headers shows the actual Cache-Control directives from the backend. This comparison helps determine whether caching issues originate in the backend or are introduced by gateway policies.

{
  "backend_status_code": "200"  // Success
}

{
  "backend_status_code": "404"  // Backend resource not found
}

{
  "backend_status_code": "503"  // Backend service unavailable
}

The time, in milliseconds, that the backend service takes to process the request and return a complete response. The measurement begins when the API Gateway sends the request to the backend and ends when the gateway receives the full response.

Performance analysis:

Example use case:

When users report slow API responses, reviewing backend_time_to_serve_request helps determine whether the backend service is the performance bottleneck or whether delays occur within gateway processing.

{
  "backend_time_to_serve_request": "1250"  // 1.25 seconds
}

The complete URL that the API Gateway uses to call the backend service. This value includes the protocol, host, port, path, and any query parameters that were part of the outgoing request.

Example use case:

When an API fails to reach the correct backend service, backend_url shows the URL the gateway attempted to call, helping you identify routing policy errors or incorrect service configurations.

{
  "backend_url": "https://api.backend.example.com:8443/v1/orders/12345"
}

{
  "backend_url": "http://internal-service.cluster.local/customers?id=789&include=orders"
}

Generated based on a hashed version of the datetime, transaction_id, and client_id fields combined by using the SHA1 algorithm.

This field is stored in JSON format and is not indexed, so it is not available for visualizations. A limited number of query requests and responses are stored for each entry, based on the amount of data that each contains. The maximum amount of data that can be stored is subject to change.

This field is stored in JSON format and is not indexed, so it is not available for visualizations. A limited number of query requests and responses are stored for each entry, based on the amount of data that each contains. The maximum amount of data that can be stored is subject to change.

This field is stored in JSON format and is not indexed, so it is not available for visualizations. A limited number of query requests and responses are stored for each entry, based on the amount of data that each contains. The maximum amount of data that can be stored is subject to change.

This field is stored in JSON format and is not indexed, so it is not available for visualizations. A limited number of query requests and responses are stored for each entry, based on the amount of data that each contains. The maximum amount of data that can be stored is subject to change.