Blog

Request API vs Sessions vs Humanized REST vs MCP: what should you use?

A practical decision guide for choosing between /v1/requests, /v1/sessions (Playwright), /v1/do (humanized tools), and MCP.

browser.city intentionally gives you four ways to ship browser automation. They overlap, but they are optimized for different workloads:

  • Request API: POST /v1/requests and POST /v1/requests/batch for “URL -> HTML/markdown”
  • Sessions API: POST /v1/sessions, then connect with Playwright for real workflows
  • Humanized REST tools: POST /v1/do/* for REST-like actions over a remote session (open, navigate, click, type, markdown, screenshots, pdf, etc.)
  • MCP server: the agent-friendly wrapper that exposes the Humanized tools to MCP clients (Codex, Claude Code, Cursor, etc.)

This guide helps you choose quickly and avoid building the wrong integration.

Fast rule of thumb

  • If you want content extraction, choose Request API.
  • If you want full control and already run Playwright, choose Sessions API.
  • If you want interactive actions but don’t want Playwright, choose Humanized REST.
  • If you want an agent to decide steps using tools, choose MCP.

Decision table

What you needPickWhy
”Fetch this URL and return markdown”Request APIFastest path, no browser client code
Crawl many URLs with retries and batchingRequest API (batch)Shared browser session across up to 100 URLs per call
Login, then navigate multiple pages, then download filesSessions APIYou own the Playwright script and session lifetime
Click/type/markdown via HTTP calls (no Playwright runtime)Humanized REST (/v1/do/*)REST-like actions over a real remote session
Test from a specific geo (or BYOP proxy)Sessions API or Request APIBoth accept egress config; pick based on interaction needs
Let an LLM agent browse/click/extract inside your editorMCPThe client discovers tools automatically; minimal glue code
You already have a Playwright crawlerSessions APISwap launch() for connect() and keep the rest

Option 1: Request API (best for extraction)

Use the Request API when your output is content, not an interactive browser artifact.

It is ideal for:

  • RAG ingestion (URL -> markdown -> chunk)
  • scraping pipelines where you don’t need logins
  • monitoring jobs (prices, listings, changelogs)

Single URL -> markdown

request.ts
const apiKey = process.env.BROWSERCITY_API_KEY!;const opts = { method: "POST", headers: { Authorization: `Bearer ${apiKey}` } };const res = await fetch("https://api.browser.city/v1/requests", {  ...opts,  body: JSON.stringify({ url: "https://example.com", markdown: true }),}).then((r) => r.json());console.log(res.content);

Notes:

  • Set "markdown": true to get clean markdown. Otherwise you get HTML.
  • Rendering is on by default. If you want “no JS”, set "render": false.

Batch URLs with a shared session

POST /v1/requests/batch runs up to 100 URLs in one shared browser session/context. That means cookies and localStorage can carry between URLs in the batch (useful for multi-page flows that don’t require a human login step).

batch.ts
const apiKey = process.env.BROWSERCITY_API_KEY!;const opts = { method: "POST", headers: { Authorization: `Bearer ${apiKey}` } };const res = await fetch("https://api.browser.city/v1/requests/batch", {  ...opts,  body: JSON.stringify({    requests: [      { url: "https://example.com", markdown: true },      { url: "https://example.com/docs", markdown: true },    ],  }),}).then((r) => r.json());console.log(res.successCount, res.errorCount);

Option 2: Sessions API (best for interaction)

Use Sessions when you need a real browser workflow:

  • authentication
  • click/typing flows
  • file downloads/uploads
  • complex “app” UIs (SPAs, dashboards)

Create a session, then connect with Playwright

session.ts
import { chromium } from "playwright";const apiKey = process.env.BROWSERCITY_API_KEY!;const opts = { method: "POST", headers: { Authorization: `Bearer ${apiKey}` } };const session = await fetch("https://api.browser.city/v1/sessions", {  ...opts,  body: JSON.stringify({    browser: "chromium",    egress: { mode: "managed", proxyType: "residential", country: "US" },  }),}).then((r) => r.json());const browser = await chromium.connect(session.endpoint, {  headers: { Authorization: `Bearer ${session.token}` },});

From here, everything is normal Playwright: create contexts/pages, click, navigate, etc.

Option 3: Humanized REST tools (/v1/do/*)

Humanized REST is “interactive browsing over HTTP”. You open a remote session, then perform simple actions via REST calls.

This is ideal when:

  • you want deterministic steps without running Playwright
  • you’re integrating into systems that are “HTTP only” (workflows, serverless jobs, internal tools)
do.ts
const apiKey = process.env.BROWSERCITY_API_KEY!;const opts = { method: "POST", headers: { Authorization: `Bearer ${apiKey}` } };const open = await fetch("https://api.browser.city/v1/do/open", {  ...opts,  body: JSON.stringify({ browser: "chromium" }),}).then((r) => r.json());const sessionId = open.result;await fetch("https://api.browser.city/v1/do/navigate", {  ...opts,  body: JSON.stringify({ sessionId, url: "https://example.com" }),});const md = await fetch("https://api.browser.city/v1/do/markdown", {  ...opts,  body: JSON.stringify({ sessionId }),}).then((r) => r.json());console.log(md.result);

Option 4: MCP server (best for agents and tooling)

MCP is the easiest way to connect browser.city to agent clients (for example: coding agents, editor assistants, and MCP-compatible frameworks).

Your MCP client discovers tools like:

  • open browser session
  • navigate
  • snapshot / markdown extraction
  • click / type / fill forms

Use MCP when:

  • you want the agent to choose which pages to open
  • you want to keep integration code minimal
  • you want “tools” instead of writing a custom Playwright harness

Common patterns that work well

  • Extract first, interact only when needed: Try Request API for 90% of URLs, fall back to Sessions only when a site requires login or interaction.
  • Keep long workflows in Sessions: If you have to log in, keep the work in the same session and avoid switching back and forth between APIs.
  • Use MCP for exploration, then productionize: Let an agent explore an unfamiliar UI with MCP tools, then codify the reliable flow in Sessions API.

MCP exposes the same Humanized primitives as tools, with tool discovery and schemas for agent clients.

[ 06 / 06 ] — Get Started

Start building in under a minute

Free tier. No credit card. Full stealth from day one.