Hyperbrowser wrapper
If you run Hyperbrowser agent tasks today, point your client at POST /api/wrappers/hyperbrowser/task — the TypeScript shim mirrors client.agents.hyperAgent.startAndWait. Your tasks default to routing: "smart" — the best runner across all providers — so pin routing: "hyperbrowser" only if you want provider parity during migration.
Why wrap vs call Responses directly
Use the Hyperbrowser wrapper when you already have Hyperbrowser client code and want the smallest diff: same method names / request shapes, Banana Peel key + base URL, optional routing. Use POST /api/v1/responses for new work — one API for smart routing, benchmarks, MFA input, and run inspection. Wrappers are a migration bridge, not the long-term product surface.
Install
npm install ./packages/wrappers/hyperbrowser→@bananapeel/hyperbrowseragents.browserUseis aliased to the same task surface — agent family names share one backend today
Before → after
import { Hyperbrowser } from "@hyperbrowser/sdk";
const client = new Hyperbrowser({
apiKey: process.env.HYPERBROWSER_API_KEY,
});
const result = await client.agents.hyperAgent.startAndWait({
task: "Go to Hacker News and tell me the title of the top post",
maxSteps: 20,
});
console.log(result.data?.finalResult);Auth & base URL
Agents: npx -y @banana-peel/cli init --agent --json (see /docs/agents). Humans who already have an account can copy a key from the keys console: bp_live_… (or bp_test_…).
- Env:
BANANA_PEEL_API_KEY, optionalBANANA_PEEL_BASE(defaults to the production Cloud Run URL) - Headers:
Authorization: Bearer …,x-api-key, or vendor-shapedx-hyperbrowser-api-key,hyperbrowser-api-key - HTTP base for this wrapper:
${BANANA_PEEL_BASE}/api/wrappers/hyperbrowser
API mapping
| Hyperbrowser | Banana Peel |
|---|---|
| agents.*.start / startAndWait | POST /api/wrappers/hyperbrowser/task |
| agents.*.get / getStatus | GET /api/wrappers/hyperbrowser/task/:id |
| task / finalResult | data (string output) + banana_peel |
| sessions / scrape / crawl | Not on this wrapper — CDP via Browserbase sessions or native Responses |
Limits / gaps
- No scrape/crawl/extract APIs, sandbox, or full CDP session surface.
- Per-agent LLM catalogs and
data.finalResultnested objects are flattened to stringdata. - Agent family names share one backend shim today.
See also
- Wrappers overview
- OpenAI-compatible Responses API (
POST /api/v1/responses) - Quickstart
- MCP server
- Migrating providers