Skyvern wrapper

If you call Skyvern today, point your client at POST /api/wrappers/skyvern/run (alias /tasks) and keep your request bodies: both modern prompt / url and older navigation_goal / website_url shapes are accepted. Your tasks default to routing: "smart" — the best runner across all providers — so pin routing: "skyvern" only if you want provider parity during migration.

Why wrap vs call Responses directly

Use the Skyvern wrapper when you already have Skyvern 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/skyvern → @bananapeel/skyvern
Familiar methods: runTask({ body, waitForCompletion }) and tasks.create

Before → after

import { SkyvernClient } from "@skyvern/client";

const client = new SkyvernClient({
  apiKey: process.env.SKYVERN_API_KEY,
});

const result = await client.runTask({
  body: {
    prompt: "Get the title of the top post",
    url: "https://news.ycombinator.com",
  },
  waitForCompletion: true,
});
console.log(result.output);

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, optional BANANA_PEEL_BASE (defaults to the production Cloud Run URL)
Headers: Authorization: Bearer …, x-api-key, or vendor-shaped x-skyvern-api-key, skyvern-api-key
HTTP base for this wrapper: ${BANANA_PEEL_BASE}/api/wrappers/skyvern

API mapping

Skyvern	Banana Peel
runTask / POST tasks	POST /api/wrappers/skyvern/run
get run / poll	GET /api/wrappers/skyvern/run/:id
prompt / navigation_goal	Responses input
extracted_information / output	`extracted_information` + `banana_peel`
TOTP / MFA	Native `POST /api/v1/responses/:id/input`

Limits / gaps

Skyvern Cloud enforces a 100-step ceiling per run. It cannot be raised via max_steps or max_steps_per_run. Banana Peel therefore emits a login → navigation → extraction workflow (no deprecated task / account for_loop). Asks that imply "all accounts" extract the visible page / the specified account and persist skyvern_account_loop_refused rather than walking a huge list until the ceiling.
A Skyvern failed + max-steps exit is not a Banana Peel hard fail when extracted JSON, a download, or a final page/DOM with the requested fields is present — that scores succeeded / answer_present. Empty extract + max-steps stays failed with skyvern_max_steps. Login/error walls stay failed (skyvern_login_failed / skyvern_blocked).
Engine enums, webhooks, and full Skyvern TOTP relay are not emulated.
Return shape uses task_id / extracted_information — not every SDK field name (run_id, output).