Modern API decisions are made inside the JSON body — not in the URL.
Traditional traffic rules typically decide based on host, path, method and header. In modern API traffic, however, the actual decision value usually lives inside the JSON body. A user's role, tenant identity, transaction type, amount, product code or GraphQL operation name may not appear in the URL at all.
This leaves the operator with two bad options. Either additional routing and security logic is pushed into the application code, or the ADC remains blind at the header and path level. Neither approach is adequate for modern API security.
In services that use JWT, the same problem exists inside the token. Only the Authorization header value is visible at the surface; the role, group, tenant or scope needed for the decision is stored in the JWT payload. If those fields cannot be read, the traffic policy cannot use identity context.
The right model is to make the JSON body and JWT content a native part of the expression language. JSONPath queries should be usable alongside traffic conditions, security rules, log enrichment and data masking actions — all in the same place.
TR7 JSON Path Operations delivers this model: JSONQUERY, JWTHEADER and JWTPAYLOAD bind API content to ADC and WAAP decisions.
Our approach
TR7 reads JSON content through the FX expression engine and carries it into traffic rules, security controls, log enrichment and response editing.
JSONQUERY reads fields directly from the body
JSONQUERY targets specific fields in the request or response body using a JSONPath expression. Those fields can then be used as traffic conditions, ACL inputs or log values.
JWTHEADER and JWTPAYLOAD make token content visible
Header and payload fields inside a JWT can be read using the same JSONPath semantics. Role, scope, tenant or user identity can be brought into traffic decisions.
JSON fields become rule conditions
Values inside the body become conditions as natural as path or header checks. Actions can be selected based on `$.tenant_id`, `$.user.role` or `$.operationName` just like any other expression.
JSON response fields can be masked or replaced
Sensitive JSON fields can be masked or substituted on the response side. Data-leak prevention is applied not only in logs but directly on the body returned to the client.
Capabilities
JSON Path Operations connects JSON body and JWT content to TR7's rule, security, log and masking layers.
JSONQUERY targets nested fields with JSONPath
JSONQUERY queries nested JSON fields directly inside the body. Expressions such as `$.user.role`, `$.items[0].sku` or `$.payment.amount` can be evaluated as rule conditions. Operators can act on decision data that never surfaces in the URL or headers. This makes it possible to manage API traffic by its actual content context.
JSON fields bind directly to ACL conditions
TR7 can use a field read from JSON as the condition of a traffic rule. For example, traffic can be routed to different backend pools based on the `tenant_id` value. If the `role` value is not acceptable, the request can be rejected. Body-aware traffic policy is established without modifying the application code.
JWT payload content signals access decisions
The JWTPAYLOAD function can read claim fields inside the token. User role, group, scope, tenant or application identity can be included in the traffic decision this way. This prevents the Authorization header from being treated as a raw token only. TR7 turns token content into a policy signal.
JWT header querying provides algorithm and token metadata checks
The JWTHEADER function can read token header fields. Algorithm, key ID or token type metadata checks can be performed. This information can be used in security rules, log entries or conditional access scenarios. The token becomes an auditable object, not just a pass-through value.
JSON values carried in headers can be parsed
Some applications carry JSON-like data structures in custom header fields. TR7 can treat those fields as parseable signals inside the expression engine as well. Structured data in headers — not just in the body — becomes part of rule evaluation. This flexibility matters in legacy integration scenarios.
Backend selection can be driven by JSON field values
In API gateway scenarios, values such as `operation`, `tenant`, `region` or `product` inside the body can serve as routing signals. TR7 can forward traffic to different backend pools based on those fields. This enables multi-application or multi-tenant separation under a single endpoint. Routing logic does not need to be embedded in the application code.
JSON fields can enrich log entries
Selected fields from the JSON body or JWT can be added to log lines. User email, tenant identity, transaction type or risk score can appear as dedicated fields in the log. This strengthens SIEM correlation. Extracting only the required fields instead of logging the full body also supports data minimization.
Sensitive fields in response JSON can be masked
TR7 can protect sensitive values in the JSON response body using mask or replace actions. Card numbers, national IDs, patient IDs, email addresses or similar fields can be targeted by regex or by path. This reduces data leak risk without requiring code changes from the application team. It works in layers alongside the sensitive data masking capability.
WAAP positive security rules can constrain JSON keys
Allowed or required fields inside the JSON body can be bound to a security policy. Unknown fields, missing required parameters or excessively nested structures can be blocked. This reduces API schema drift and injection surface. JSON content inspection goes beyond negative security signatures.
JSON depth and key count limits improve parser safety
JSON payloads that are deeply nested or contain excessive keys can exhaust application and parser resources. TR7 can enforce limits such as JSON nesting depth and key count as security policy. This reduces the impact of API DoS attempts and unexpected body structures. Limits can be tuned per endpoint sensitivity.
Malformed JSON requests can be rejected before reaching the backend
If JSON cannot be parsed, the request is not treated as a trusted API body. TR7 can reject or log requests with malformed JSON before forwarding them to the backend. This reduces unexpected parse errors at the application layer. It also provides visibility for distinguishing attack traffic from misbehaving clients.
JSON queries compose with other FX functions
A JSONQUERY result can be used together with string, regex, map, list, IP or hash functions. For example, a tenant value is extracted from JSON, looked up in a map table, and the result drives a routing or block decision. This makes the JSON query a part of the policy engine, not just a standalone helper. Complex API decisions can be expressed in the visual rule editor.
Operational depth
JSON operations are operated together with body buffering, parse error handling, JWT field behavior, log minimization, response editing and performance limits.
Body access timing
The body must be readable before a JSON query can run. Body-aware rules therefore require more processing than header-only rules. They should be applied only on endpoints where they are genuinely needed.
Parse error behavior
If JSON cannot be parsed, policy can produce a rejection, a log entry or a different action. If an API endpoint expects JSON, a malformed payload should not be forwarded to the backend. This behavior improves endpoint security.
JWT trust assumption
Reading JWT content and verifying the token are not the same operation. If JWT claim values are to be used in traffic decisions, signature verification and trust-source policy must be configured separately. Otherwise an attacker can craft false claims.
Log minimization
Extracting only the required fields instead of logging the full JSON body is the more secure approach. Fields such as tenant, operation or status can be logged; sensitive fields should be masked. This balances SIEM visibility with data protection.
Response editing limits
Response JSON masking operates on the body, so response size and content type matter. Performance and memory impact on very large responses should be planned. Correct endpoint and field targeting is required to apply sensitive data protection effectively.
Performance impact
JSON parsing and path querying cost more than header checks. If multiple JSON queries are used within the same request, result reuse is important. Rules should be designed so that unnecessary repeated parsing does not occur.
When to use it
Route to backend by tenant ID value
A SaaS API may receive traffic from multiple tenants on a single endpoint. TR7 can read the `$.tenant_id` field and forward traffic to the correct backend pool for each tenant.
Enforce access control on JWT role claims
The role or scope value inside an Authorization token can be read. Access to admin paths can be restricted to users whose token carries the required claim value.
Mask sensitive fields in response JSON
Card numbers, identity numbers or user data returned in an API response can be masked. TR7 reduces the exposure of sensitive fields in outbound responses without requiring application code changes.
Reject malformed JSON before it reaches the backend
When a JSON-expecting endpoint receives a malformed body, TR7 can reject the request early. This reduces application parse errors and shrinks the attack surface.
Enrich log lines with operation and tenant data
Instead of logging the full body, only fields such as `operationName`, `tenant` and `userId` are extracted. SIEM correlation improves and data minimization is preserved.
Frequently asked questions
Which JSONPath syntax does JSONQUERY support?
Is signature verification performed automatically when reading JWT content?
How does performance hold up when multiple JSON fields are read in the same request?
Does JSON masking apply only on the response side?
What does TR7 do when it receives a malformed JSON body?
How does this capability relate to the sensitive data masking page?
Make API body content part of your traffic and security decisions
JSONQUERY, JWTHEADER and JWTPAYLOAD turn JSON body fields and JWT claims into rule conditions, log entries and masking actions. Let's walk through a live setup on your own services.