Derive Client

Derive an API client from a recorded session

Driving a browser is the right tool for the first visit and the wrong tool for the hundredth. This skill records a site's network traffic once while you use it, then turns the captured requests into a standalone client (script, CLI, or library) that talks to the site's internal API directly.

The recording alone contains everything needed: agent-browser embeds text response bodies (JSON/HTML/JS) in the HAR by default, so endpoint shapes can be studied offline after the browser is closed.

Workflow

Copy code
1. Record     Start HAR capture, drive the flows you want in the client
2. Identify   Find the real API endpoints among the noise
3. Extract    Pull request shapes, response schemas, and auth material
4. Generate   Write the client, one function per flow
5. Verify     Call every endpoint for real before declaring done

1. Record

bashCopy code
agent-browser network har start          # embeds text response bodies by default
# ... drive the site: search, open a detail page, paginate, etc. ...
agent-browser network har stop /tmp/site.har

• Exercise every flow the client should support, and run each one at least twice with different inputs (two search terms, two detail pages). Diffing the recorded URLs reveals which parts are parameters.
• If the site needs login, log in before starting the HAR so credentials don't land in the recording unnecessarily. The session cookies are exported separately in step 3.
• --content all embeds binary bodies too (base64); --content none disables embedding. Per-body cap is 2 MB.

While the session is still open, agent-browser network requests and network request <id> give the same data interactively — but only the HAR survives navigation and browser close, so prefer it for anything multi-page.

2. Identify endpoints

Query the HAR with jq:

bashCopy code
# All JSON API calls: method, URL, status
jq -r '.log.entries[]
  | select(.response.content.mimeType | test("json"))
  | "\(.request.method) \(.response.status) \(.request.url)"' /tmp/site.har

Ignore analytics and infrastructure noise: telemetry endpoints (/collect, /track, /beacon, /log), third-party domains (google-analytics, segment, sentry, datadog, intercom, hotjar), and static assets. The real API is usually first-party, JSON, and correlates with the actions you performed.

3. Extract shapes and auth

bashCopy code
# Full detail for one endpoint: request headers, POST body, response body
jq '.log.entries[] | select(.request.url | test("api/search"))
  | {request: {method: .request.method, headers: .request.headers,
     postData: .request.postData.text},
     response: .response.content.text}' /tmp/site.har

• Response schema: read .response.content.text — this is the real payload, use it to derive types.
• Auth: compare request headers across endpoints. Look for authorization, cookie, x-csrf-token, x-api-key, and site-specific x-* headers. Replay only the ones that matter — test by omission in step 5.
• Cookies: export the live session with agent-browser cookies get --json > cookies.json for the client to load at runtime. Never hardcode cookie values into generated source.

4. Generate the client

• One function per recorded flow (search(query), getItem(id)), typed from the observed response bodies.
• Auth material (cookies, bearer tokens) loads from a file or environment variable, with a clear error telling the user to re-run the browser login when it expires.
• Reproduce the headers the API actually requires — some sites 403 without a matching user-agent, referer, or x-requested-with.
• Keep pagination, sort, and filter parameters that appeared in the recorded query strings as function options.

5. Verify

Call every generated function against the live API and compare the response shape with the recording. Common failures:

Caveats

• Internal APIs are unversioned and change without notice — keep the HAR so the client can be re-derived.
• Respect the site's terms of service and rate limits; add delays for bulk fetching.
• HAR files contain live session credentials (cookies, tokens, POST bodies). Treat them like secrets: keep them out of version control and delete them when done.