Compatibility wrappers

Already shipping with Browserbase, Steel, Browser Use, Skyvern, or Hyperbrowser? Keep the client shape — change the key to bp_live_…, point at Banana Peel, and tasks are smart-routed across all runners by default. Wrappers are a migration bridge; new integrations should use the Responses API (POST /api/v1/responses).

Wrap vs call Responses directly

Use a wrapper when you want the smallest code change and already speak a vendor SDK/REST shape (tasks, runs, sessions).
Use Responses when you want smart routing, benchmarks, MFA /input, and one stable contract across every runner.

// Preferred for new code
const res = await fetch(`https://bananapeel.com/api/v1/responses`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.BANANA_PEEL_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "banana-peel",
    input: "Return JSON with the title",
    url: "https://example.com",
    routing: "smart",
  }),
});

Install matrix

TypeScript clients live in packages/wrappers/* in the Banana Peel repo (private / path-install for now). They call the HTTP surfaces below with familiar method names.

Provider	Package	HTTP surface	Notes
Browserbase	@bananapeel/browserbase	/api/v1/sessions	Official @browserbasehq/sdk + baseURL, or thin helper
Steel	@bananapeel/steel	/api/wrappers/steel/…	tasks + optional /v1/sessions proxy
Browser Use	@bananapeel/browser-use	/api/wrappers/browser-use/…	runs.create / waitForCompletion
Skyvern	@bananapeel/skyvern	/api/wrappers/skyvern/…	runTask / navigation_goal
Hyperbrowser	@bananapeel/hyperbrowser	/api/wrappers/hyperbrowser/…	agents.hyperAgent.startAndWait

export BANANA_PEEL_BASE=https://bananapeel.com
export BANANA_PEEL_API_KEY=bp_live_…

# Wrapper packages live under packages/wrappers:
npm install ./packages/wrappers/steel
# or import via path / tsx:
# import { Steel } from "./packages/wrappers/steel/src"

Concept mapping

How vendor vocabulary maps to Banana Peel. The runner (banana_peel.runner) is the service that executed the work; routing is what you request. Provider tasks map to Banana Peel runs (a unit of work, routed and billed per attempt); provider sessions stay sessions (a live browser you hold open and drive over CDP) — see Runs vs. sessions.

Their concept	Banana Peel
API key (vendor)	bp_live_… / BANANA_PEEL_API_KEY
Task / run / job	Response + run (`banana_peel.run/v1` on wrappers)
Provider / model pin	`routing` — named runner, list, category, or `smart`
Who ran it	`banana_peel.runner`
Browserbase session / CDP	`/api/v1/sessions` (proxied — a real single-provider browser, not smart-routed)
Steel session	`/api/wrappers/steel/v1/sessions` (optional proxy — always runs on Steel)
MFA / OTP	`POST /api/v1/responses/:id/input`

Migration checklist

Agents: run npx -y @banana-peel/cli init --agent --json (see /docs/agents). Humans who already have an account can manage keys at /keys and set BANANA_PEEL_API_KEY.
Pick your provider page below — swap base URL / install the in-repo package.
Smoke-test one create + poll; confirm banana_peel.runner in the response.
Task wrappers default to routing: "smart" — no change needed to get routing across all runners. Optionally pin your old provider (e.g. routing: "steel") or a fallback list for parity during a gradual migration.
Plan the cutover to native Responses when you next touch that code path.

Provider guides

Browserbase — /api/v1/sessions
Steel — /api/wrappers/steel/…
Browser Use — /api/wrappers/browser-use/…
Skyvern — /api/wrappers/skyvern/…
Hyperbrowser — /api/wrappers/hyperbrowser/…

MCP server — coding agents without hand-rolled HTTP
Quickstart
Migrating providers
For AI agents / llms.txt