Generated banner for Browser To API
Generated logo for Browser To API

Browser To API

BrowserbaseOfficialPublished by Browserbase

  • Skill
  • Content generator
  • Software development
  • MIT
  • Low risk
  • Has scripts

From the author

Turn a website's observable HTTP traffic into a best-effort OpenAPI 3.1 spec by analyzing a `browser-trace` capture. Use when the user wants to discover/extract API endpoints from a browser session, build an OpenAPI doc from network traffic, or document a third-party site's XHR/fetch surface for client integration.
— the description by Browserbase

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Browser to API is a post-processing workflow that transforms recorded browser network traffic into structured OpenAPI 3.1 documentation. By analyzing CDP event logs and optional network body captures, it infers API schemas, templates URL paths, and decomposes multiplexed endpoints like GraphQL. The tool produces a comprehensive suite of artifacts, including a machine-readable YAML/JSON spec, a zero-dependency client, and a self-contained HTML report for visualizing discovered operations.

What it does

  • Parses browser-trace network logs to reconstruct API activity.
  • Infers JSON schemas from observed request and response bodies.
  • Automatically templates URL paths by identifying dynamic segments like UUIDs.
  • Decomposes multiplexed endpoints such as GraphQL into distinct logical operations.
  • Filters out common infrastructure noise like analytics, tracking, and bot defense traffic.
  • Generates a self-contained HTML report and a ready-to-use client.mjs file.

When to use it

  • You need to document an undocumented or third-party website API.
  • You are building a client or SDK for a service that lacks a public API specification.
  • You want to generate an OpenAPI spec based on real-world usage patterns.
  • You need to analyze which API endpoints are triggered by specific browser flows.

Advantages

  • Creates specifications based on actual observed traffic rather than assumptions.
  • Provides a visual, interactive report for easy exploration of discovered endpoints.
  • Includes automatic noise reduction to focus on relevant API traffic.
  • Supports complex dispatch patterns like GraphQL and JSON-RPC.
  • Generates a functional client snippet alongside the documentation.

Usage examples

“Generate an OpenAPI spec from my recent browser-trace run.”
The skill processes the .o11y/run-name directory and outputs an openapi.yaml, a client.mjs file, and an index.html report.
“I only want to document the API endpoints for api.example.com.”
The skill uses the --origins flag to filter out noise from other domains, resulting in a cleaner, more focused specification.
“How can I get response body schemas in my generated spec?”
The skill explains that you must use the browser-trace network capture feature and pass the resulting directory to the --bodies flag during generation.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/browserbase/browser-to-api/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip browser-to-api.zip -d .agents/skills

Documentation by Browserbase

Browser to API

Replay-driven API discovery. Consume a browser-trace capture, pair its CDP request / response events, templatize observed URLs, infer JSON schemas from samples, and emit an OpenAPI 3.1 document plus a human-readable coverage report.

This skill does not capture traffic. It is purely offline post-processing on top of browser-trace's cdp/network/*.jsonl buckets. The two skills compose:

browser-trace    →  .o11y/<run>/cdp/network/{requests,responses}.jsonl
browser-to-api   →  .o11y/<run>/api-spec/index.html + openapi.yaml + client.mjs

When to use

  • The user wants an OpenAPI document for a third-party or undocumented website API.

  • The user has a browser-trace run and wants endpoints + schemas extracted from it.

  • The user is building a client/SDK against a site that doesn't publish a spec.

  • The user wants a coverage report showing which flows would broaden the spec.

If the user wants to capture traffic, send them to browser-trace first.

Two-step workflow

1. Capture with browser-trace (and optionally bodies via browse network on)
# Local example against an existing debuggable Chrome target
TARGET=9222

node ../browser-trace/scripts/start-capture.mjs "$TARGET" my-site
browse open about:blank --cdp "$TARGET"
browse network on                                    # capture request/response bodies
browse open https://example.com
# ...drive whatever flows you want covered...

# Snapshot the bodies dir BEFORE turning capture off (the temp dir is shared
# per-session, so subsequent `browse network on` runs would mix your bodies
# with whatever a future capture writes if you skip this step).
cp -r "$(browse network path | jq -r .path)" .o11y/my-site/cdp/network/bodies/
browse network off

node ../browser-trace/scripts/stop-capture.mjs my-site
node ../browser-trace/scripts/bisect-cdp.mjs my-site

browse network on is optional but strongly recommended — without it, the spec has no response-body schemas (the CDP firehose used by browse cdp does not embed bodies). With it, both request bodies (already captured by CDP) and response bodies are joined into the trace by CDP requestId.

2. Generate the spec
node scripts/discover.mjs --run .o11y/my-site
# → .o11y/my-site/api-spec/index.html          ← open this
#   .o11y/my-site/api-spec/client.mjs
#   .o11y/my-site/api-spec/openapi.yaml
#   .o11y/my-site/api-spec/openapi.json
#   .o11y/my-site/api-spec/report.md
#   .o11y/my-site/api-spec/confidence.json
#   .o11y/my-site/api-spec/samples/*.json
#   .o11y/my-site/api-spec/intermediate/*.jsonl

discover.mjs auto-detects <run>/cdp/network/bodies/. To use a body capture from elsewhere (e.g. didn't snapshot, want the live browse network dir), pass --bodies <path> explicitly.

3. Open the HTML report

After discover.mjs finishes, always open the generated HTML report:

open .o11y/my-site/api-spec/index.html

The report is a self-contained HTML file (no server needed) that shows each discovered operation as an expandable card with variables, client usage, request/response examples, and a generated client.mjs snippet at the bottom. This is the primary deliverable — always open it for the user.

CLI flags

FlagRequiredMeaning
--run <path>yesPath to a browser-trace run directory
--out <path>noOutput dir; default <run>/api-spec/
--bodies <path>nobrowse network capture dir to join into the trace (auto-detected from <run>/cdp/network/bodies/ when present)
--include <regex>noOnly include URLs matching regex (repeatable)
--exclude <regex>noExclude URLs matching regex (repeatable; in addition to defaults)
--origins <list>noComma-separated origin allow-list (e.g. api.example.com,example.com)
--format <yaml|json|both>noOutput format. Default both
--title <string>noOpenAPI info.title. Default derived from primary origin
--redact <list>noExtra header names / JSON keys to redact (comma-separated)
--min-samples <n>noMinimum samples per endpoint to include. Default 1
--stage <name>noRun only one stage: load, filter, normalize, infer, emit

Output layout

<run>/api-spec/
├── index.html                visual report — open this (self-contained, no server)
├── client.mjs                zero-dep fetch client with typed functions per operation
├── openapi.yaml              machine-readable spec
├── openapi.json              mirror
├── report.md                 markdown summary + curl examples
├── confidence.json           per-endpoint confidence + normalization flags
├── samples/                  redacted request/response examples
│   └── <method>__<path-hash>.json
└── intermediate/             pipeline byproducts (paired/filtered/endpoints jsonl)

What you get from browse cdp and browse network

Two complementary capture sources:

SourceProvidesLimitation
browse cdp (used by browser-trace)request method/URL/headers/postData, response status/headers/mimeType, full event timingDoes not embed response bodies. Bodies must be pulled with Network.getResponseBody, which the firehose doesn't do.
browse network on (separate command)request bodies AND response bodies on disk, keyed by CDP requestIdCapture dir is shared per browse session; snapshot before another browse network on overwrites it.

discover.mjs will pull bodies from a browse network dir if you pass --bodies <path> (or stash them under <run>/cdp/network/bodies/, which is auto-detected). The matching is by requestId — browse network writes that into each request.json as id, and we join directly.

What changes when bodies are present:

  • ✅ Path templating, query-param schemas, status codes, content-types — same either way.

  • ✅ Request-body schemas — postData from CDP is enough; bodies dir is a nice-to-have for non-postData cases.

  • ✅ Response-body schemas — fully inferred from real samples. Without bodies you get { description, content: <mimeType> } skeletons.

The report flags every endpoint that has no response-body sample.

Automatic noise filtering

The normalize stage automatically classifies and drops infrastructure noise:

  • Tracking / analytics — paths containing /track, /pixel, /beacon, /impression, /pageview, /dag/v*

  • Bot defense — Akamai (/akam/), fingerprint payloads (sensor_data), obfuscated multi-segment paths

  • Session plumbing — /session, /authenticate/start, cookie consent, A/B experiment endpoints

  • HTML page renders — GET requests returning text/html (the rendered page, not the API)

This typically drops 60-80% of captured traffic. The --include flag can rescue a false positive.

GraphQL / multiplexed endpoint decomposition

When a single endpoint (like /dapi/fe/gql) is called with different operationName values, the skill automatically splits it into separate logical operations. Each gets its own:

  • OpenAPI path entry (e.g. /dapi/fe/gql [Autocomplete])

  • Request/response schema inferred from only that operation's samples

  • Curl example and variables table in the report

Detection works on body fields (operationName, method, action) and query params (opname, op). This covers GraphQL (APQ and inline), JSON-RPC, and similar dispatch patterns.

Limitations

  • Coverage is bounded by the captured flow. Endpoints not exercised in the trace will not appear. The skill cannot prove completeness.

  • Schemas are inductive, not contractual. A field might be optional on the server even if every sample contained it.

  • Auth is observed, not specified. The skill records auth-shaped headers in an x-observed-auth extension but won't claim a security scheme.

  • Path templating is heuristic. Numeric / UUID / hex / slug patterns are detected per segment. Ambiguous URLs are flagged in confidence.json.

  • Redaction is best-effort. Default redactions cover common credentials, but app-specific secrets may slip through; use --redact for known custom headers/keys.

Best practices

  1. Drive the flows you want documented. The richer the browser-trace, the richer the spec.

  2. Use --origins for noisy sites. A marketing page hits dozens of analytics hosts; restrict to the API origin you care about.

  3. Inspect report.md first. It has curl-ready examples and response samples for every discovered operation.

  4. Bump --min-samples to 2+ when you want only confidently-shaped endpoints in the final doc — drop the long tail.

  5. Pair with browse network on when response-body schemas matter. The CDP firehose alone has request bodies but not response bodies.

For pipeline internals and the file format reference, see REFERENCE.md.

Files

REFERENCE.md

Browser to API — Reference

Exhaustive reference for every script, flag, file format, and configuration knob the skill exposes.

Scripts

All scripts are Node ESM (type: module). They depend only on the Node standard library. discover.mjs is the top-level dispatcher; the others are stage scripts the dispatcher calls in order. Run an individual stage with discover.mjs --stage <name> for debugging or partial reruns.

discover.mjs --run <path> [flags]

Top-level dispatcher. Runs load → filter → normalize → infer → emit in order. With --stage <name>, runs only that stage (assumes prior stages already wrote their intermediate file).

open-swagger-ui.mjs (--run <path> | --spec <path>) [flags]

Preview an emitted OpenAPI spec in a local Swagger UI checkout. The script serves the Swagger UI dist/ assets and the generated spec from one local HTTP origin, injects a per-run swagger-initializer.js, opens the browser by default, and keeps the server alive until interrupted.

  • --run <path> loads <run>/api-spec/openapi.yaml, falling back to openapi.json.

  • --spec <path> previews an explicit OpenAPI YAML/JSON file.

  • --swagger-ui <path> points at a Swagger UI checkout/package directory. If omitted, the script tries $SWAGGER_UI_DIR, ~/Developer/swagger-ui, and node_modules/swagger-ui-dist.

  • --host <host> defaults to 127.0.0.1.

  • --port <port> defaults to a random free port.

  • --no-open prints the URL without opening a browser.

load.mjs <run-path> <out-dir> [bodies-dir]
  • Reads cdp/network/requests.jsonl and cdp/network/responses.jsonl.

  • Pairs by requestId. Drops OPTIONS (CORS preflight) and pure redirects (status 3xx with Location and no body — recorded as metadata on the next request in the chain when the requestId carries forward, otherwise dropped).

  • Drops resource types that are not XHR, Fetch, or Document (skips Image, Stylesheet, Font, Media, Manifest, Other, Script unless the URL clearly looks like an API endpoint).

  • Body join: if a browse network capture dir is provided (via --bodies or auto-detected at <run>/cdp/network/bodies/), each subdir's request.json + response.json are read and joined to paired rows by requestId. The browse-network id field IS the CDP requestId for XHR/Fetch resource types, so the join is exact (not URL-or-timestamp matching). Bodies that look like JSON are parsed; otherwise the raw string is preserved.

  • Output: intermediate/paired.jsonl — one row per pair with { method, url, status, reqHeaders, reqBody, respHeaders, respBody, contentType, type, ts }.

filter.mjs <run-path>
  • Reads intermediate/paired.jsonl.

  • Applies --include / --exclude / --origins.

  • Applies built-in exclude list (analytics hosts, sourcemaps, service workers, fonts/CSS that snuck through).

  • Output: intermediate/filtered.jsonl.

normalize.mjs <run-path>
  • Templatizes paths. Detection order per segment:

    1. UUID v1–v5 → {id} (string, format: uuid).

    2. Pure integer → {id} (integer).

    3. Hex/base62 ≥ 8 chars → {id} (string).

    4. If the same position varies across multiple samples and is short alpha → {slug} (string).

    5. Otherwise the segment is left static.

  • Groups paired samples by (origin, method, templatedPath).

  • Collects query parameters across samples; marks required: true only when every sample carries the param.

  • If two pre-normalization templates would collapse but yield divergent response status/content-type signatures, they're kept split and flagged.

  • Output: intermediate/endpoints.jsonl — one row per endpoint with { origin, method, path, samples[], queryParams, statusCodes, normalizationFlags }.

infer.mjs <run-path>
  • For each endpoint, runs JSON-Schema inference across request bodies and (when present) response bodies.

  • Merge rules: required = present-in-all, types = union of observed types, arrays infer item schema, enum detected when ≤ 8 distinct values across ≥ 5 samples.

  • Format hints: date-time (ISO-ish), uri, email, uuid.

  • Picks a representative sample (most-recent successful 2xx) and writes redacted request/response example to samples/.

  • Output: intermediate/endpoints.with-schemas.jsonl.

emit.mjs <run-path>
  • Builds the OpenAPI 3.1 document.

  • Hoists structurally-identical schemas into components.schemas keyed by structural hash, with names derived from path tokens (Item, Item_List, etc.) — falls back to Schema1, Schema2 if no path hint applies.

  • Writes openapi.yaml, openapi.json, report.md, confidence.json.

File formats

intermediate/paired.jsonl
{
  "requestId": "12345.678",
  "method": "GET",
  "url": "https://api.example.com/v1/items/42?page=2",
  "origin": "https://api.example.com",
  "path": "/v1/items/42",
  "query": { "page": "2" },
  "status": 200,
  "type": "Fetch",
  "contentType": "application/json",
  "reqHeaders": { "accept": "application/json" },
  "reqBody": null,
  "respHeaders": { "content-type": "application/json" },
  "respBody": null,
  "ts": 1714400000000
}

reqBody is the verbatim postData from Network.requestWillBeSent (parsed if JSON). respBody is null unless a browse network capture dir was joined in (see below) — browse cdp does not embed bodies.

Joining browse network bodies

browse network on is a separate command from the browse CLI that writes per-request request.json + response.json files (with full bodies) to a temp directory. Discover joins these into the trace by requestId.

Workflow:

# during capture, alongside browser-trace
browse network on
# ...drive...
# IMPORTANT: snapshot the dir before it gets reused
cp -r "$(browse network path | jq -r .path)" .o11y/<run>/cdp/network/bodies/
browse network off

Internals (matched in lib/io.mjs + load.mjs):

  • The browse-network entry's request.json.id field equals the CDP requestId for XHR/Fetch resource types. The join is by exact requestId, not URL or timestamp.

  • For Document loads, the id field is a non-CDP UUID and won't match — those bodies are silently skipped (Documents aren't useful for API spec inference anyway).

  • response.json from browse network may have empty status / headers / mimeType for some loads — that's fine, those are taken from the CDP firehose. Only body is read.

  • The capture dir is shared per browse daemon session (/tmp/.../browse-default-network/). Run browse network on then snapshot the dir before another browse network on overwrites it.

intermediate/endpoints.jsonl
{
  "endpointKey": "GET https://api.example.com/v1/items/{id}",
  "origin": "https://api.example.com",
  "method": "GET",
  "path": "/v1/items/{id}",
  "rawPaths": ["/v1/items/42", "/v1/items/97"],
  "pathParams": [{ "name": "id", "in": "path", "schema": { "type": "integer" } }],
  "queryParams": [{ "name": "page", "in": "query", "required": false, "schema": { "type": "string" } }],
  "statusCodes": [200, 200, 404],
  "samples": [/* indices into paired.jsonl */],
  "normalizationFlags": []
}
confidence.json
{
  "endpoints": [
    {
      "key": "GET /v1/items/{id}",
      "samples": 7,
      "statusCodes": [200, 404],
      "responseBodyKnown": false,
      "requestBodyKnown": false,
      "normalizationFlags": [],
      "confidence": "medium"
    }
  ]
}

confidence is a coarse bucket: low (1–2 samples or normalization flags), medium (3–9 samples, no flags), high (≥ 10 samples, multi-status, no flags).

CLI flags (full)

FlagDefaultNotes
--run <path>requiredResolves cdp/network/{requests,responses}.jsonl underneath
--out <path><run>/api-spec
--bodies <path>autobrowse network capture dir to join into the trace. Auto-detected from <run>/cdp/network/bodies/ when present
--include <regex>noneRepeatable. ORed together. Applied after --origins
--exclude <regex>(defaults)Repeatable. Combined with built-in defaults
--origins <list>noneComma-separated. If set, anything not matching is dropped before include/exclude
--format <yaml|json|both>bothFormat of the emitted spec
--title <string>derivedinfo.title in the OpenAPI doc
--redact <list>(defaults)Comma-separated extra header names / JSON keys to scrub. Adds to defaults; never replaces
--min-samples <n>1Drop endpoints below this threshold (still listed in the report)
--stage <name>(all)One of load, filter, normalize, infer, emit

Swagger UI preview flags

FlagDefaultNotes
--run <path>required unless --spec is setResolves a browser-trace run and previews <run>/api-spec/openapi.yaml or openapi.json
--spec <path>required unless --run is setExplicit OpenAPI YAML/JSON path
--swagger-ui <path>autoCheckout/package dir containing either dist/index.html or index.html + swagger-ui-bundle.js
--host <host>127.0.0.1Preview server bind host
--port <port>randomPreview server bind port
--no-openfalsePrint the URL without launching the browser

Default exclude list

URLs matching these patterns are dropped before any analysis (regex, applied to the full URL):

  • Analytics: segment\.(io\|com), mixpanel\.com, google-analytics\.com, googletagmanager\.com, datadog(hq)?\.com, sentry\.io, amplitude\.com, fullstory\.com, hotjar\.com, intercom\.io, clarity\.ms, cloudflareinsights\.com, doubleclick\.net, facebook\.com/tr

  • Static-only file extensions: \.(png|jpe?g|gif|svg|webp|ico|woff2?|ttf|eot|otf|css|map|mp4|webm|mp3)(\?|$)

  • Service worker / metadata: /sw\.js, /service-worker\.js, /manifest\.json$, /robots\.txt$, /favicon\.ico$

Override granularly via --include (which wins over default --exclude).

Default redactions

Headers (case-insensitive): authorization, cookie, set-cookie, x-csrf-token, x-xsrf-token, x-api-key, proxy-authorization, plus any header name matching *token*, *secret*, *signature*.

Body keys: password, token, secret, api_key, apiKey, accessToken, refreshToken, creditCard, ssn.

Body values (regex): JWTs (^eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+$), email addresses (@ + TLD), phone numbers (E.164-ish).

Redacted values are replaced with "<redacted>" so type information is preserved for schema inference.

Path templating heuristics

Per-segment classifier in scripts/lib/path-template.mjs:

PatternReplacementOpenAPI schema
8-4-4-4-12 hex (UUID){id}{ type: string, format: uuid }
\d+{id}{ type: integer }
[A-Za-z0-9]{8,} (no vowels-only / dictionary check){id}{ type: string }
Same-position alpha tokens varying across ≥ 2 samples{slug}{ type: string }

When multiple variable segments exist in one path, names are suffixed: {id}, {id2}, {id3}. The --name-params flag (future) will use sibling segment hints (/products/42 → {productId}).

Confidence flags

Possible entries in normalizationFlags:

  • divergent-response-shape — pre-normalization paths collapsed to the same template but had structurally different responses. The skill keeps them split and emits both.

  • single-sample — endpoint observed exactly once.

  • single-status — only one status code observed; spec lists only that response.

  • mixed-content-types — different content-type values across samples.

  • request-body-only-on-some-samples — POST/PUT seen with and without a body.

OpenAPI extensions

The emitter writes a few x-* extensions on each operation:

  • x-confidence: { samples, statusCodes, normalizationFlags }

  • x-origin: the origin this operation was observed on (when multiple servers are listed)

  • x-observed-auth: array of auth-shaped header names seen on this endpoint (e.g. ["authorization", "x-api-key"])

  • x-sample-count: total number of paired samples backing the operation

These extensions are stripped from report.md (which is human-facing) but preserved in the YAML/JSON.

Configuration via env

VarDefaultEffect
O11Y_ROOT.o11yInherited from browser-trace. Used only when --run is bare run id rather than a full path
DISCOVER_ENUM_MAX_DISTINCT8Max distinct values to consider a field an enum
DISCOVER_ENUM_MIN_SAMPLES5Min samples before enum detection runs
SWAGGER_UI_DIRautoOptional Swagger UI checkout/package dir for open-swagger-ui.mjs

Troubleshooting

SymptomLikely causeFix
paired.jsonl is emptytrace contains no Network.requestWillBeSent events for XHR/Fetchre-run browser-trace exercising the dynamic flows; static-only sites won't yield endpoints
openapi.yaml has only paths: {}every paired request was filtered outcheck --origins and the default exclude list; pass --include '.*' to bypass filtering
Path templating collapses too aggressivelynumeric IDs being misread as enums, or dictionary words misread as slugsadd --exclude for the noisy paths and re-run, or file an issue with the trace
Schemas show type: "string" for everythingrequest/response bodies aren't valid JSON or weren't capturedcheck paired.jsonl for reqBody/respBody content — if null, bodies weren't in the trace
Spec validator complains about info.versionderived version is 0.1.0-discovered which some tools dislikepass --version 0.1.0 (TODO) or post-edit the file
Swagger UI not foundno local Swagger UI checkout/package was detectedclone https://github.com/swagger-api/swagger-ui to ~/Developer/swagger-ui, or pass --swagger-ui <path> / set SWAGGER_UI_DIR

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Needs Node.js

The author says: Requires Node 18+ and a `browser-trace` run directory (`.o11y/<run>/`) produced by the sibling `browser-trace` skill. The scripts use only the Node standard library — no `npm install` step. `jq` is referenced in docs for ad-hoc querying but is not required by the scripts.

Security

What our scanner noticed· Low risk

  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Browserbase
Publisher
Browserbase (Official)
Source
browserbase/skills · skills/browser-to-api · commit 6811ca3
Licence
MIT License (redistribution allowed)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Browserbase or Browserbase.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download browser-to-api.zip