In most organizations the API inventory lives in application documentation, outdated schema files or lists maintained by individual teams. But applications change with every release: new endpoints are added, old ones are forgotten, test paths are left in production. Security teams typically learn which APIs are active in real traffic after the application teams do.
This gap amplifies shadow API and zombie endpoint risk. An undocumented endpoint may sit outside the WAF policy entirely; an endpoint that should no longer be in use may still be reachable. From an attacker's point of view these areas are low-visibility, weakly protected and worth probing.
Relying solely on an externally provided schema file is also insufficient. If the schema is not current it will not match real traffic. The application team may have changed an endpoint without updating the schema, or a path that never appears in the schema may be running in production. In that case the protection policy rests on an outdated assumption rather than real application behavior.
The traditional negative security model does not solve this problem on its own. Blocking known attack patterns is important, but the real strength in API security is explicitly defining the permitted methods, headers, parameters, MIME types and body fields. Without positive security, unknown but apparently valid malicious requests can pass through unchallenged.
TR7 API Discovery & Schema closes this gap: it learns API behavior from real traffic, supports schema generation from the OpenAPI flow or rule generation from a schema, and brings positive security controls inline.
TR7 applies API discovery together with traffic learning, positive schema, size and depth limits, and per-field validation.
TR7 can learn path and method behavior from real traffic and build endpoint patterns. Paths containing variable IDs, dates or tokens are normalized into a more readable API inventory.
Allow-lists can be defined for methods, headers, query parameters, JSON keys, XML elements, form fields and MIME types. Rather than only searching for known bad patterns, the policy explicitly declares expected API behavior.
Limits such as path length, path depth, header count, query count, JSON depth, XML depth and raw body size can all be applied. These limits ensure that oversized or overly complex requests are checked before they reach the backend.
Regex validation can be defined for every header, query parameter, form field or body field. Email, phone, ID, country code or service-specific formats are checked at field level.
API Discovery & Schema turns the learned endpoint inventory into enforceable positive security rules.
TR7 can analyze path and method information from incoming requests to derive endpoint patterns. Paths such as `/api/users/123` and `/api/users/456` can be grouped under a single logical pattern. This approach makes endpoints that are not in documentation but are actively running in production visible. The API inventory is based on real traffic behavior, not assumptions.
TR7 is positioned to support a workflow for generating OpenAPI-compatible schemas from learned API behavior. In the reverse direction, TR7 rules can be generated from an OpenAPI schema provided by the user. This two-way model reduces the gap between real traffic and the documented API contract. The operator uses the same platform for both discovery and enforcement.
The list of permitted methods — GET, POST, PUT, DELETE, PATCH and others — can be defined per endpoint. If a POST is sent to an endpoint that only expects GET, for example, that behavior can be treated as a policy violation. A method-based allow-list is a simple but effective positive security layer. Incorrect or abusive endpoint behavior is caught earlier.
Permitted headers and query parameters can be defined per endpoint. For each field, a name, value format and regex validation can be applied. Unexpected headers or parameters can be tied to a security score, alert or block. Data outside the API contract is therefore not passed to the backend unchecked.
TR7 can build allow-lists at the JSON key, XML element and form field level. Required fields can be defined with mustArgs; unknown fields can be excluded from the allowed list. This structure describes the expected request body rather than only searching for attack signatures. API endpoints are protected in a way that stays closer to their own contract.
Allow-lists for permitted MIME types can be defined for form and raw body. Sending data to a JSON-expecting endpoint with a different content type can be treated as a policy violation. This control is especially important for file upload or form-based APIs. Content type becomes a direct input to the security decision.
Overall size limits can be applied for headers, query strings, forms, JSON, XML and raw body. JSON and XML nesting depth controls prevent overly deep payloads from adding load to the parser and the backend. Limits such as key count, value count, per-field length and duplication count can also be defined. These controls create a protective boundary for both security and performance.
Some endpoints may not need to accept JSON or XML bodies at all. TR7 can provide controls to disable JSON or XML body use entirely on a per-endpoint basis. This stops unexpected body formats from reaching the backend. It is particularly effective for plain GET endpoints and services that do not accept non-form transactions.
Regex-based validation can be applied for every header, query parameter, form field or body field. Email, phone, UUID, numeric ID, country code or organization-specific formats are checked in this way. Out-of-format values are not left to the application to handle — they are caught at the edge. This model brings the data-format dimension of the API contract into the security policy.
Endpoints learned from traffic can be compared against the existing documented API list. Active endpoints not in the documentation can be flagged as shadow API candidates; endpoints that should no longer receive traffic but still do can be flagged as zombie endpoint candidates. These recommendations are presented as learning suggestions for the operator to review, not as absolute enforcement decisions. Security teams can map the real API surface more quickly.
Over time, new JSON keys, new query parameters or different method usage may appear. TR7 can make differences between learned behavior and the current schema policy visible. These differences may signal an application version change, a misbehaving client or an abuse attempt. The operator can accept the change and add it to the schema or treat it as a policy violation.
API discovery helps report which endpoints were active during a given period. Questions such as "Which endpoints received traffic in the last 30 days?" are important for security and compliance teams. A traffic-based inventory provides a more realistic audit baseline than a static document. The organization monitors its API surface against live behavior.
API discovery and schema controls operate across path, query, header, form, JSON, XML and raw scopes.
TR7 schema controls cover path, query, header, form, JSON, XML and raw fields. Each scope can carry its own limits, allow-lists and validation rules. API security is therefore defined across the full request surface, not just the body.
Schema rules can be defined with different types such as complexInput, regex, numeric, boolean and enumSelect. Simple on/off controls and detailed field lists are managed within the same DSL. The operator selects the rule type based on the API behavior.
Rules can be applied at different target levels: web application, api endpoint and application server. This allows a distinction between a general service policy and a schema specific to a single endpoint. Choosing the right scope produces a policy with less repetition and a clearer area of effect.
The learning model can hold per-path nodes, frequency counts and child path information. Summary information can be extracted by host or service group. This structure helps understand which parts of the API surface are high-traffic, sparse or newly appearing.
Learned changes can be submitted for admin approval rather than applied automatically. The operator reviews proposals for new endpoints, new fields or new patterns and converts the appropriate ones into policy. This model positions learning as guided decision support rather than uncontrolled automation.
Historical log files can be analyzed in batch to derive API behavior retrospectively. This means the discovery process is not limited to live traffic only. Earlier traffic periods, campaign windows or incident moments can be examined separately.
Security teams can compare the endpoint list learned from real traffic against the existing API documentation. Active paths not present in the documentation are taken in for review as shadow API candidates.
Microservice teams can see each service's endpoint behavior from traffic without waiting for manual documentation. TR7 helps turn the path-and-method-based inventory into a security policy.
Compliance teams can report which endpoints were active during a given period. This makes the API surface that handles data more clearly visible during an audit.
If endpoints opened for test or staging appear in production traffic, they can be noticed within the learning recommendations. The operations team can then close, restrict or place them under the correct security policy.
Traffic-based endpoint inventory, shadow API visibility and positive schema rules — let's walk through a live setup on your own services.