A report you can actually reason about.

What this example represents

This is an illustrative report for a fictional inventory application. No network scan was performed to generate these records. The routes, identities, observations, and evidence descriptions are invented to explain report structure. They are not findings about your systems or the ApiScanner.com website.

The sample inventory contains eight routes, uses two synthetic test roles, and shows three observations. All three require review. Two scoped route checks are represented as complete, two as incomplete, and four inventory routes are not assessed. No overall security score or pass verdict is implied.

Scope and run status

The fictional host is inventory.example.test in an authorized staging environment. Viewer and editor are the two synthetic roles. Payment providers, production services, vendor infrastructure, and destructive operations are excluded.

The run status is incomplete because the example does not demonstrate every scoped question. A report can contain useful observations while still having coverage gaps. Keep that status separate from the review state of individual findings.

Route inventory and coverage

An inventory entry tells you that a route is known, not that its behavior was verified. Each completed check still has a limited role, scenario, and purpose. Unassessed routes remain unknown.

Three observations, three explicit next actions

EXAMPLE-001 / Review required

Authorization evidence is incomplete

Expected: Deny access to a synthetic record belonging to another warehouse.

Observed: The illustrative record does not include the cross-warehouse response.

Evidence: SYNTHETIC-A01 — Invented worksheet notes record an intended ownership test but no observed response.

Next action: An authorized reviewer should confirm the synthetic identity and capture the approved permitted and denied cases.

EXAMPLE-002 / Review required

A legacy route needs an owner

Expected: Every inventoried route has a documented owner and lifecycle decision.

Observed: The illustrative inventory contains a legacy route without an owner.

Evidence: SYNTHETIC-I02 — The fictional inventory row has no assigned maintenance owner; no runtime behavior is asserted.

Next action: Assign an inventory owner to confirm whether the route remains supported, is retired, or needs documentation.

EXAMPLE-003 / Review required

Error-response review needs context

Expected: An error response should disclose only information needed by the intended caller.

Observed: The example worksheet notes a field named debug_context but supplies no complete response or interpretation.

Evidence: SYNTHETIC-R03 — An invented field label alone is insufficient to establish exposure or business impact.

Next action: Review a sanitized response in the approved environment and confirm whether the field contains unnecessary information.

What belongs in the evidence

A useful record identifies the application revision, test role, expected behavior, observed behavior, and a reference an authorized reviewer can inspect. A status code or severity label alone is not enough. Avoid retaining unnecessary response bodies, customer records, or credentials.

How a reviewer should use this report

First confirm the scope and run quality. Then validate an observation in the approved staging environment before assigning impact or a repair. Keep contradictory evidence visible and document any rejected finding or temporary exception.

After a repair, repeat the narrowly scoped failing case and a legitimate permitted case. Record the retest evidence rather than merely changing the finding to green. The security workflow describes that decision process.

Take the report structure with you

Download the same illustrative JSON report or read the API integration guide to understand its fields. Use the scope checklist for a real assessment brief. Replace invented records with your own authorized evidence; do not present the sample as a completed scan.