---
title: "SPA Endpoint & Parameter Map"
canonical: https://trickest.com/library/spa-endpoint-and-parameter-map
description: "Map the route, API and parameter attack surface of a modern JS app (Next, Nuxt, React) from its JS bundles. No browser, no auth."
---

# SPA Endpoint & Parameter Map

## Overview

A modern JavaScript app does not link its real attack surface. The routes, the
`/api` endpoints, the dynamic segments and the query parameters all live in the
client bundle, referenced by the router but never printed in the HTML a crawler
reads. So a normal crawl of a Next, Nuxt or React site sees the homepage and a
handful of links, and misses most of what the app can actually do. This workflow
recovers it: it pulls the app's JavaScript chunks and its `__NEXT_DATA__` payload
and mines them for every path and parameter the client knows about, runs a crawl
alongside, and merges the two into one deduplicated, classified surface. Each
endpoint is tagged with the source that found it, so you can see exactly which
ones only the JS mining reached. It is token-free and uses no browser, which is
what lets it fan across thousands of hosts, and it gives
[offensive security](/use-cases/offensive-security) the endpoint list a DAST or a
manual test actually needs.

## Pipeline

1. [httpx](/tools/httpx) confirms the target is live and fingerprints its stack.
2. Two miners run against it in parallel. The JS miner pulls the app's
   `_next/static` chunks and its `__NEXT_DATA__` / RSC payload and regex-mines
   them for page routes, `/api` endpoints, dynamic route segments and query
   parameters, and adds the paths from `sitemap.xml` and `robots.txt`.
   [katana](/tools/katana) crawls the rendered app and captures its XHR calls.
3. The two sets and the httpx fingerprint are merged, deduplicated by host and
   path, and classified into API, dynamic and page routes, with each endpoint
   carrying the sources that found it.
4. The classified surface is written to a report.

## Inputs

- **Target list.** The hosts to map, as domains or URLs, one per line. Point it
  at scope you are authorised to test.

## Outputs

- **Endpoint surface.** One row per endpoint, carrying its path, type (API,
  dynamic or page route), the HTTP methods seen, the query parameters, and the
  sources that found it.
- **Per-source attribution.** Whether each endpoint came from the JS mining, the
  crawl, the sitemap, robots or the fingerprint, so the ones a crawler alone
  would have missed are visible.
- **Report.** The classified surface and its counts in one file, ready to feed a
  DAST run or a manual review.

## Sample output

Illustrative, in the record shape the workflow emits. Real runs name live hosts,
so the target here is a documentation domain.

Each endpoint carries its type, parameters and the sources that found it. The
`js-mine`-only rows are the ones a crawler alone would have missed:

```jsonl
{"path": "/api/v2/search", "type": "api-route", "methods": ["GET"], "params": ["q", "cursor"], "sources": ["js-mine"]}
{"path": "/api/checkout/session", "type": "api-route", "methods": ["POST"], "params": [], "sources": ["js-mine"]}
{"path": "/customers/[slug]", "type": "dynamic-route", "methods": ["GET"], "params": [], "sources": ["js-mine", "katana"]}
{"path": "/dashboard/settings", "type": "page-route", "methods": ["GET"], "params": [], "sources": ["js-mine"]}
{"path": "/", "type": "page-route", "methods": ["GET"], "params": [], "sources": ["katana", "httpx"]}
```

The run summary counts the surface it recovered:

```json
{"endpoints": 261, "api_routes": 38, "dynamic_routes": 24, "params": 96, "js_mine_only": 71}
```

## FAQ

### What does the JS mining find that a crawler misses?

The routes and API calls the client bundle references but the server never
renders as links: lazy-loaded pages, admin sections behind a feature flag, the
`/api` calls a button makes on click, and the query parameters those calls take.
A crawler only sees what is linked in HTML, so on a SPA it sees a fraction of the
app. Reading the JavaScript is what recovers the rest.

### How complete is it, honestly?

It recovers close to all of the statically reachable surface and a large share of
all public pages. The remainder are links that only exist once the client renders
them into the DOM, and no browser-free method can reach those. The workflow is
explicit about which endpoints came from which source, so you are never guessing
about coverage.

### Does it need a browser or credentials?

No. It reads the JavaScript and the app's data payload over plain HTTP, the way
any client downloads them, with no headless browser and no login. That is what
lets one run fan out across thousands of hosts at once.

### Which frameworks does it handle?

It is framework-agnostic and tuned for Next.js, both the App and Pages routers,
where it also reads `__NEXT_DATA__`. Nuxt, React and other bundlers are covered
by the same generic chunk and parameter mining, since nothing is hardcoded per
site.

## Related workflows

- [Sitemap URL & Metadata Extractor](/library/sitemap-url-extractor). Reach for
  this when a site publishes a real sitemap and you want its content inventory
  rather than the client-side routes a sitemap never lists.
- [Directory and Content Discovery](/library/directory-and-content-discovery).
  Reach for this to brute force paths a server exposes but neither the HTML nor
  the JavaScript references at all.

---
_Markdown source of https://trickest.com/library/spa-endpoint-and-parameter-map._