Manual API discovery depends on a tester browsing the application, capturing traffic, identifying endpoints, and building a spreadsheet or schema by hand. Automated schema generation reduces that labour by extracting endpoints and constructing the OpenAPI picture from proxy traffic. The practical difference is speed and consistency, especially when the application exposes many hidden or nested API calls.
Why the Difference Matters in Test Coverage
The distinction is not just about convenience. Manual API discovery gives a tester more context about how the application behaves, which can help uncover unexpected routes, undocumented features, and gaps between intended and actual access patterns. Automated schema generation, by contrast, is better at scale and repeatability, but it only sees what the traffic reveals and what the proxy can parse. For teams testing modern applications, that means the method chosen affects coverage, confidence, and how quickly gaps are found. In practice, many teams discover missing endpoints only after a proxy-based pass has already been used to validate the happy path.
For teams that need a control-oriented view of testing discipline, the NIST SP 800-53 Rev 5 Security and Privacy Controls catalogue is useful because it frames how organisations should evidence repeatable security assessment rather than rely on ad hoc inspection.
How Manual Discovery and Automated Generation Behave in Practice
Manual discovery is labour-intensive because it depends on human observation. A tester navigates the interface, watches network calls, follows links, repeats actions with different inputs, and infers how the API is organised. That approach can surface APIs that are not obvious from the frontend, but it is slow and inconsistent across testers. It also relies heavily on the tester noticing patterns, such as versioned paths, alternate request bodies, or endpoints that appear only after certain roles or workflows are exercised.
Automated schema generation uses a proxy or similar capture point to observe traffic and convert it into a structured representation, usually an OpenAPI-style schema. This works well when the application emits clear, regular requests and responses, and when the traffic includes enough functional breadth to represent the API surface. It is especially useful when testers need a quick inventory to support regression testing, fuzzing, or documentation checks. It is less effective when traffic is sparse, heavily dynamic, compressed in ways the tool cannot parse, or when important calls are triggered only by unusual paths or privileged workflows.
- Manual discovery is strongest when the tester needs exploratory breadth and can tolerate slower coverage.
- Automated generation is strongest when the goal is fast, repeatable inventory building from observed traffic.
- Both methods depend on test quality: if the application is not exercised, neither method will fully reveal hidden functionality.
In practice, teams get the best results when they use automated generation to establish a baseline and then apply manual exploration to challenge what the schema missed.
Where the Two Approaches Diverge
Tighter automation increases speed, but it also increases the chance that undocumented behaviour remains unseen, so organisations have to balance efficiency against discovery depth. That tradeoff matters most in applications with conditional routes, role-specific APIs, or asynchronous calls that do not appear in ordinary browsing.
The main practical difference is that manual discovery captures tester intent, while automated generation captures observed behaviour. That means the second approach is usually more consistent across test runs, but it can also be more misleading if the captured traffic is incomplete or biased toward one user journey. Manual work is better for interrogating edge behaviour, but it is harder to reproduce and harder to scale across large applications. There is no universal consensus that one method replaces the other; most mature testing programmes use them as complementary steps rather than competitors.
For practitioners, the edge case to watch is tooling confidence: a polished schema can create a false sense of completeness even when the underlying traffic sample was narrow. The guidance breaks down when teams treat generated output as a full inventory instead of a starting point for further validation.
Risk and Threat Considerations
The main risk in either approach is incomplete visibility. If discovery misses hidden, nested, or role-dependent endpoints, testers can overlook security-relevant functionality such as admin actions, data export paths, or alternate update methods. That creates a coverage gap rather than a direct vulnerability, but coverage gaps are often what allow real defects to survive into production.
Failure mechanism: Manual discovery can miss endpoints because of human fatigue or limited path exploration, while automated generation can miss them because the proxy never sees the right traffic or cannot parse the request pattern. Attackers benefit from the same blind spots when undocumented endpoints remain untested or insufficiently validated.
Impact: The result can be an incomplete test inventory, missed authorisation flaws, and weaker assurance that the application’s exposed API surface has actually been reviewed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 18 — Penetration Testing | API discovery supports security testing scope and coverage. |
| Recommendation — Use penetration testing to validate that discovered API coverage is complete and security-relevant. | ||
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | Observed traffic and endpoint inventory support monitoring of exposed API behaviour. |
| ID.RA — Risk Assessment | Discovery gaps affect assessment of application exposure and testing completeness. | |
| Recommendation — Continuously monitor API traffic to catch undocumented or unexpected endpoints. Assess incomplete API discovery as a coverage risk in your application security reviews. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Undocumented APIs can expand exploitable attack surface on exposed applications. |
| Recommendation — Map exposed API routes to T1190 and test them for exploitable weaknesses. | ||
Practitioner Guidance
What to prioritise: Treat the generated schema as a working artefact, not a source of truth. The first question is whether the captured traffic covered all meaningful user roles, states, and workflows, because that determines whether the output is useful or merely tidy.
What to verify: Confirm that hidden methods, secondary routes, and non-standard responses were exercised during capture. If the schema looks too neat, it is usually because the traffic sample was too narrow rather than because the API is simple.
Decision rule: Use automation for speed and repeatability, then switch to manual exploration wherever the application has conditional logic, role gating, or low-frequency calls that matter to security testing.
Practitioner takeaway: The best testing posture is not choosing one method over the other, but using automation to accelerate discovery and manual work to challenge its blind spots.
Related resources from NHI Mgmt Group
- What is the difference between API discovery and API security testing?
- What is the difference between REST oriented API scanning and JSON-RPC schema driven testing?
- What is the difference between automated DAST and manual penetration testing in an enterprise AppSec programme?
- What is the difference between automated data discovery and manual data discovery?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
