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.
TR7 reads JSON content through the FX expression engine and carries it into traffic rules, security controls, log enrichment and response editing.
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.
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.
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.
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.
JSON Path Operations connects JSON body and JWT content to TR7's rule, security, log and masking layers.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
JSON operations are operated together with body buffering, parse error handling, JWT field behavior, log minimization, response editing and performance limits.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
Instead of logging the full body, only fields such as `operationName`, `tenant` and `userId` are extracted. SIEM correlation improves and data minimization is preserved.
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.