Short answer. Most SaaS APIs we test do not have current OpenAPI documentation. Some have a Swagger spec that is 18 months out of date. Some have a Postman collection one engineer maintains. Some have nothing. We have a 5-step discovery methodology that builds a working endpoint inventory from traffic capture, frontend bundle inspection, source code review when shared, GraphQL introspection when applicable, and direct probing. Documentation speeds the engagement by ~25 percent but is not a prerequisite. Most critical findings we have shipped were in endpoints the customer’s documentation did not list at all.
Documentation is supposed to make pentesting easier. In practice, the documentation a customer hands over at kickoff is usually one of three things: missing, stale, or aspirational. We have learned to start from the assumption that the documentation, if it exists, is a hint, not the source of truth.
This is the methodology we use to pentest an API when there is no current spec. The same methodology runs alongside a full OpenAPI spec when one exists, because the spec rarely matches reality.
Why missing documentation is the common case
Three patterns produce undocumented APIs.
Velocity outpaced documentation. A Seed-stage startup ships features weekly. Documentation lags. By the time a pentest is scoped, the documented endpoints are six months behind the actual API. Every team we have worked with in this stage has this problem.
Documentation lives in different places. Some endpoints are in Swagger. Some are in a Notion doc. Some are in Postman collections owned by individual engineers. Some are in code comments. The team intends to consolidate someday. Someday has not come.
The API evolved past its documentation framework. A REST API that grew GraphQL extensions, a v1 that still serves alongside v2, an internal endpoint that became external during a partner integration. The original OpenAPI spec described the original API. The current API is a superset.
For any of these cases, the documentation is partial signal. Useful, but not the test plan.
The 5-step discovery methodology
flowchart LR
A[1. Traffic capture<br/>via proxy] --> B[2. Frontend bundle<br/>inspection]
B --> C[3. Source code<br/>review if shared]
C --> D[4. GraphQL<br/>introspection]
D --> E[5. Direct probing<br/>conventional paths]
E --> F[Endpoint inventory<br/>+ categorized test plan]
Step 1: Traffic capture from the running application. We set up a man-in-the-middle proxy (Burp Suite or mitmproxy) and walk every user-facing flow with the customer’s product. Log in, click through the main screens, walk through workflows. Every API request the frontend makes gets captured. After 60-90 minutes of this, we have a baseline endpoint inventory covering 70-80 percent of what users actually hit.
Step 2: Frontend bundle inspection. A React or Next.js or Vue bundle contains the URL strings the frontend ever calls. We grep the production JavaScript bundles for URL patterns (fetch(, axios., apiClient., route constants). This surfaces endpoints the frontend can call but does not call during normal user flow. Conditional admin endpoints. Feature-flagged endpoints. Error-recovery endpoints that only fire in specific states.
Step 3: Source code review when shared. If the customer shares backend source code (most do not for pentests, but some do for SOC 2 audit-grade engagements), we extract the route definitions directly. For Express, that means walking app.use and router.X registrations. For FastAPI or Spring, the route decorators. This is the most comprehensive single source when available. Customers who do not share code can sometimes share a route table export or a server log capturing the live routes registered at startup.
Step 4: GraphQL introspection (if applicable). If the API has a GraphQL endpoint, the first test is introspection. If introspection is enabled in production (it often is, by accident), the schema is downloadable in 5 seconds. The schema enumerates every type, every query, every mutation. If introspection is disabled, we use schema-inference techniques: gradient queries, error message analysis, and (where available) public client documentation. GraphQL endpoints that disable introspection but expose verbose errors are common and almost as informative.
Step 5: Direct probing for common patterns. Some endpoints are convention-based and findable by educated guessing. /api/v1/users, /api/v1/users/me, /api/v1/orders, /api/admin, /api/internal, /healthz, /metrics, /v2/graphql. We probe a list of ~50 conventional paths against the API. A surprising number of endpoints turn up this way, especially admin and debug routes left in production by accident.
The output of these five steps is an endpoint inventory that we cross-reference against any documentation the customer did provide. The delta (endpoints in our inventory that the documentation does not list) often contains the most interesting findings, because those endpoints have not been thought about recently.
Building the test plan from discovery
The endpoint inventory is the input. The test plan is the output.
For each discovered endpoint, we record:
- HTTP method (GET, POST, PUT, PATCH, DELETE, custom)
- Authentication state required (none, user-token, admin-token, API key, mTLS)
- Parameters accepted (query, body, headers)
- Response shape (what data comes back)
- Tenant scope (single-tenant, multi-tenant via path, multi-tenant via query, etc.)
From this, we cluster endpoints by category: authentication, user management, billing, admin, partner-facing, read-only public, internal. Each category gets a specific test battery.
Authentication endpoints get token forgery, replay, refresh-flow tests, brute-force, password reset, and multi-factor bypass tests. Billing endpoints get IDOR (can user A see user B’s invoices), price tampering (can user modify totals), refund-callable-twice tests. Admin endpoints get the missing-auth check (can a regular user hit them), and the privilege-escalation chain (can a multi-step request escalate). Each category is several hundred test cases in the worst case, dozens in the typical case.
The test plan is then prioritized. Highest priority: endpoints in categories that handle credentials, payments, or PII. Lowest priority: read-only public endpoints with no auth. We do the full test plan in the time we have. If time runs short, the priority order determines what gets tested first.
What this looks like in practice
A representative recent engagement. Customer: Series A SaaS, Indian market, payment-adjacent vertical. Documentation provided: a 14-month-old Swagger file covering ~40 endpoints. Initial scope estimate based on the spec: 7-day engagement.
Discovery output: 87 endpoints across REST and GraphQL surfaces. The Swagger file accurately described 32 of them. 8 were missing from the spec entirely, all internal admin or debug routes. 47 were partially documented (parameters changed, response shape evolved). Among the 8 undocumented endpoints, two were critical findings: a /api/internal/users/impersonate endpoint left from a debug session that accepted any authenticated user and switched session to the requested user, and a deprecated /v1/admin/export endpoint that was supposed to be retired in v2 but still responded with no auth required.
Neither of those would have shown up in a documentation-driven test. Both showed up in step 1 (traffic capture surfaced the first) and step 5 (direct probing surfaced the second).
This is the typical pattern. Documented endpoints are tested either way. Undocumented endpoints produce a disproportionate share of the critical findings. The methodology exists to ensure the undocumented endpoints get tested.
What you can do as a client to make discovery faster
If you are scoping an API pentest and want to shave time off the discovery phase, four things help most.
Two test accounts in different tenants. For multi-tenant SaaS, the tenant-isolation tests need two accounts that own different resources. Provisioning these upfront saves a half-day of back-and-forth during the engagement. See our breakdown of API pentest vs web app pentest for why tenant isolation is the highest-impact test category.
Whatever documentation you do have, in whatever form. A 12-month-old Swagger is more useful than no Swagger. A Postman collection one engineer maintains in their personal account is fine. A list of routes from a server log capture is fine. Send what you have; do not waste a week trying to clean it up first.
A 30-minute walkthrough of the main user flows. One of your engineers screens-shares the product and walks through 5-10 flows. This is faster than us building a mental model from scratch and lets us ask “what about X?” questions in real time. Most customers find this valuable for them too, because explaining the product to an outside tester surfaces assumptions.
A staging environment with realistic data. Pentesting against production is sometimes unavoidable but slows the engagement because we have to limit destructive tests. A staging environment with realistic-enough data lets us run more aggressive tests, find more, and report more.
None of these is required. Each shortens the discovery phase by a meaningful amount.
Where this fits in the broader pentest methodology
Discovery is one phase. After discovery, the engagement moves through threat modeling (mapping what attackers might want), test plan execution (running the categorized batteries against each endpoint), exploitation (chaining findings where possible), and reporting. For broader context, our OWASP API Security Top 10 explainer walks the vulnerability categories we test for, and What agents can and can’t test in your API covers why automated discovery alone is not enough.
If you want to scope a pentest for an undocumented API, book a 30-minute discovery call and we can walk through what your engagement would look like before you commit. If you would rather start with a free pass, run an OpenEASD scan to get a baseline of your external surface, then come back when you are ready to scope an actual API pentest.
Cybersecify is a founder-led penetration testing and security consulting firm serving AI-first and API-first SaaS startups in India. Both founders are on every engagement: Rathnakara GN (OSCP, CompTIA PenTest+, M.Sc Cyber Security) leads pentest delivery, Ashok S Kamat leads consulting and client work.