# Browser To API

Turn a website's observable HTTP traffic into a best-effort OpenAPI 3.1 spec by...

- Repository: https://github.com/browserbase/skills (3748 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-10-27
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add browserbase/skills --skill browser-to-api -g -a claude-code -y`
Codex: `npx skills add browserbase/skills --skill browser-to-api -g -a codex -y`
Cursor: `npx skills add browserbase/skills --skill browser-to-api -g -a cursor -y`
Gemini CLI: `npx skills add browserbase/skills --skill browser-to-api -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add browserbase/skills`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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`)

```bash
# 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
```

The rest: https://github.com/browserbase/skills/blob/HEAD/skills/browser-to-api/SKILL.md