🔄 synced local 'docs/' with remote 'docs/'

This commit is contained in:
andrewneilson 2026-04-27 00:14:06 +00:00
parent 9fcfffd85f
commit 8a30ef8a42
71 changed files with 934 additions and 340 deletions

View file

@ -0,0 +1,68 @@
---
title: Authentication & 2FA
subtitle: Log in to any site, including sites with multi-factor authentication
description: Skyvern handles logins with stored credentials, TOTP/authenticator codes, email and SMS verification, magic links, and password manager integrations with Bitwarden, 1Password, and Azure Key Vault.
slug: developers/features/authentication-and-2fa
icon: key
keywords:
- authentication
- login
- 2FA
- MFA
- TOTP
- magic link
- SSO
- Bitwarden
- 1Password
- Azure Key Vault
---
Most browser automations hit a login wall within the first few seconds. Skyvern handles authentication end-to-end, from simple passwords to multi-factor flows with TOTP codes, email verification, and magic links. Secrets live in your vault and never touch the LLM.
## What's supported
**Credential types:** passwords (with optional TOTP secret bundled in), credit cards for checkout automations, and arbitrary secrets or API keys.
**2FA methods:**
- **TOTP / authenticator apps** store the secret once and Skyvern generates valid codes on every run.
- **Email or SMS codes** can be pushed to Skyvern via API, or you can expose an endpoint that Skyvern polls every 10 seconds until the code arrives.
- **Magic links** work the same way: push the one-time login URL and Skyvern detects and follows it automatically.
- **Multi-field TOTP** handles split-box layouts (one digit per input) by filling all fields with the same code.
**Vault integrations:** Bitwarden (Cloud and self-hosted / Vaultwarden), 1Password (via service account token), Azure Key Vault, and a custom HTTP vault option if you want to bring your own service.
## How credentials stay safe
When a run needs a credential, Skyvern fetches it from your vault, injects it directly into the browser's form field, and discards it as soon as the field is filled. The value never enters an LLM prompt, never lands in a log line, and never gets written to any persistent Skyvern storage.
You'll see this in practice: run recordings, action timelines, and LLM prompts show stable placeholder tokens like `BW_PASSWORD`, `BW_USERNAME`, and `BW_TOTP` wherever real credentials were used. The prefix reflects the vault source (`BW_` for Bitwarden, `OP_` for 1Password, `AZ_` for Azure Key Vault, `SK_` for Skyvern's built-in vault) so you can audit which credential fired without the secret ever leaving your vault.
## Learn more
<CardGroup cols={2}>
<Card
title="Store credentials"
href="/developers/credentials/store-credentials"
>
Create passwords, cards, and secrets. Wire up Bitwarden, 1Password, Azure, or a custom vault.
</Card>
<Card
title="Handle 2FA"
href="/developers/credentials/handle-2fa"
>
TOTP setup, pushed codes, polled endpoints, and magic links.
</Card>
<Card
title="Troubleshoot logins"
href="/developers/credentials/troubleshooting-login"
>
Debug 2FA and login failures.
</Card>
<Card
title="SDK reference"
href="/sdk-reference/browser-automation/agent-login"
>
`agent.login()`, `send_totp_code()`, and the credentials API.
</Card>
</CardGroup>

View file

@ -0,0 +1,64 @@
---
title: Browser Sessions
subtitle: Keep a live browser open across multiple tasks and workflows
description: Skyvern browser sessions are live browser instances that persist cookies, local storage, and page state across runs. Use them for back-to-back tasks, human-in-the-loop flows, and real-time agents.
slug: developers/features/browser-sessions
icon: window-restore
keywords:
- browser sessions
- persistent state
- human-in-the-loop
- real-time agent
- cookies
- local storage
- browser profile
---
A Browser Session is a live browser instance that Skyvern keeps running between runs. Cookies, local storage, open tabs, and the current page all persist, so later operations pick up exactly where the previous one stopped.
## What you can build
**Back-to-back tasks:** log in with one operation, search and extract with the next, with no re-authentication in between.
**Human-in-the-loop flows:** pause for approval between steps without losing browser state. The VNC stream lets you watch or take control at any point.
**Real-time agents:** keep a browser open for hours while the agent responds to events as they happen.
**Task and workflow chaining:** run tasks and workflows through the same live browser instance, mixing code-driven and UI-defined automation in a single session.
## Configuration
Sessions support timeouts from 5 minutes to 24 hours (defaulting to 60 minutes), proxy locations across any of Skyvern's [21 supported countries](/developers/going-to-production/proxy-geolocation), Chrome or Edge browser types, and built-in extensions for ad-blocking and CAPTCHA solving. Every session exposes a live VNC stream.
## Sessions vs. Profiles
Sessions are live browsers that bill while open. [Browser Profiles](/developers/optimization/browser-profiles) are saved snapshots of browser state you reuse across days or weeks. You can create a profile from a finished session to save its authenticated state for later.
## Learn more
<CardGroup cols={2}>
<Card
title="Browser sessions guide"
href="/developers/optimization/browser-sessions"
>
Create sessions, run operations through them, and close cleanly.
</Card>
<Card
title="Browser profiles"
href="/developers/optimization/browser-profiles"
>
Save state to reuse across days or weeks.
</Card>
<Card
title="Connect your local browser"
href="/developers/self-hosted/browser"
>
Use your own Chrome with its existing logins and extensions.
</Card>
<Card
title="SDK reference"
href="/sdk-reference/browser-sessions/create-browser-session"
>
`create_browser_session`, `get_browser_session`, `close_browser_session`.
</Card>
</CardGroup>

View file

@ -0,0 +1,85 @@
---
title: CAPTCHA & Bot Bypass
subtitle: How Skyvern handles CAPTCHAs and avoids triggering anti-bot systems
description: Learn how Skyvern automatically detects and solves CAPTCHAs including reCAPTCHA, hCaptcha, and Cloudflare Turnstile, and how to reduce bot detection risk using residential proxies, browser sessions, and browser profiles.
slug: developers/features/captcha-and-bot-bypass
icon: shield-halved
keywords:
- CAPTCHA
- reCAPTCHA
- hCaptcha
- Cloudflare Turnstile
- bot detection
- fingerprinting
- residential proxy
- stealth
- anti-bot
---
Skyvern detects CAPTCHAs using its vision model and solves them automatically. This works for reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstile, FunCaptcha/ArkoseLabs, MTCaptcha, and standard text/number image CAPTCHAs.
That said, CAPTCHA solving is not guaranteed. Solvers can fail on novel challenges or rate-limited IPs. The rest of this page covers what Skyvern does automatically and what you can do to improve your success rate.
## Built-in bot detection avoidance
Every run gets these protections automatically, with no configuration needed:
- The `AutomationControlled` Blink feature flag is disabled so the browser isn't marked as automated.
- `navigator.webdriver` is hidden by suppressing the `enable-automation` flag, which defeats the most common JavaScript detection scripts.
- Viewport and user agent are set to match real consumer browsers.
- Locale and timezone auto-match the proxy location, so you never end up with a mismatched fingerprint (an English locale on a Japanese IP, for example).
## Reducing detection risk
Beyond fingerprinting, how you structure your automation affects whether you get flagged.
**Use residential proxies for sensitive sites.** Datacenter IPs are the single most common bot signal. Residential proxies route through real ISP addresses. Set `proxy_location="RESIDENTIAL"` or use `RESIDENTIAL_ISP` for a static IP that persists across the session. See [Proxy & Geolocation](/developers/going-to-production/proxy-geolocation).
**Reuse browser sessions for multi-step flows.** Creating a fresh browser for every step is suspicious. A persistent session maintains cookies, cache, and history between operations. See [Browser Sessions](/developers/optimization/browser-sessions).
**Use browser profiles for repeat visits.** Profiles save browser state from a previous session. The site sees a known browser with familiar cookies instead of a blank slate. See [Browser Profiles](/developers/optimization/browser-profiles).
**Add wait blocks between rapid actions.** Instant back-to-back actions can trigger behavioral detection. A short pause between steps looks more human.
## If you get blocked
Increase `max_steps` first, because some bot challenges (especially Cloudflare) loop through multiple verification pages and the solver needs more attempts. If that doesn't help, switch to a `RESIDENTIAL_ISP` proxy for a static IP that services trust more. Try loading a browser profile that previously passed the challenge on that domain. You can also load Chrome extensions for additional stealth by setting `EXTENSIONS` and `EXTENSIONS_BASE_PATH` in your environment.
## Manual fallback
If automatic solving fails and you need a human in the loop, you can manually solve any CAPTCHA without cancelling the run. In the Cloud UI, go to **Runs**, click your run, and click the **Take Control** button over the browser stream. Release control when you're done and the agent resumes where you left off.
<img src="/images/take-control.png" />
## Self-hosted deployments
Automatic CAPTCHA solving is not available for self-hosted deployments. When a CAPTCHA is detected, the agent pauses for 30 seconds to allow manual intervention. Solve it in the browser window yourself, then the agent continues automatically.
## Related
<CardGroup cols={2}>
<Card
title="Proxy & Geolocation"
href="/developers/going-to-production/proxy-geolocation"
>
Route traffic through residential proxies in 21 countries.
</Card>
<Card
title="Handle 2FA"
href="/developers/credentials/handle-2fa"
>
Configure TOTP, email, and SMS verification codes.
</Card>
<Card
title="Browser Sessions"
href="/developers/optimization/browser-sessions"
>
Persist browser state across multiple runs.
</Card>
<Card
title="Error Handling"
href="/developers/going-to-production/error-handling"
>
Map CAPTCHA and bot failures to custom error codes.
</Card>
</CardGroup>

View file

@ -0,0 +1,73 @@
---
title: Code Caching
subtitle: Convert successful runs into cached code for faster, deterministic replays
description: Skyvern records the actions an AI run takes and generates executable code from them. Subsequent runs execute the cached code directly, skipping LLM inference and screenshot analysis. Faster, cheaper, deterministic.
slug: developers/features/code-caching
icon: bolt
keywords:
- code caching
- code generation
- run_with
- Skyvern 2.0 with Code
- deterministic runs
- script generation
- cost optimization
- progressive caching
---
When Skyvern's agent completes a task or workflow, it records the actions it took and generates reusable code from them. Later runs can execute that cached code directly, skipping LLM inference and screenshot analysis entirely. This makes cached runs faster, cheaper, and deterministic. If the cached code fails because a page changed, Skyvern falls back to the agent automatically and regenerates the cache.
## How it works
The first run uses the agent as normal. Set `engine="skyvern-2.0"` when creating the task or workflow, and Skyvern records the actions as generated code while the agent executes.
On subsequent runs, pass `run_with="code"` to execute the cached code directly. No screenshots, no LLM reasoning, just the recorded action sequence replaying against the page.
If the cached code hits something unexpected (a layout change, a new field, a missing element), Skyvern re-runs with the full agent and regenerates the cache. You don't need to handle this yourself.
<Note>
The SDK default engine is `skyvern-1.0`. To use code caching, explicitly set `engine="skyvern-2.0"`. In the Cloud UI, `skyvern-2.0` is the default.
</Note>
## What gets cached
**Tasks** cache the full action sequence the agent took: clicks, form fills, extractions, and navigation.
**Workflows** cache per block. Each block that successfully executes gets its own cached script, so a partially-cached workflow still saves time on the blocks that have been seen before.
**Progressive caching** handles workflows with conditionals. Run 1 covers branch A, run 2 covers branch B, and so on. Previous caches are preserved, so coverage builds up over time.
**Not cached:** conditional evaluation blocks, wait blocks, and code blocks always run live because their behavior depends on runtime state.
<Tip>
Pair cached code with [scheduled workflows](/cloud/building-workflows/scheduling) for cheap, reliable recurring runs. The first scheduled run builds the cache, and every subsequent run executes from it.
</Tip>
## Learn more
<CardGroup cols={2}>
<Card
title="Cost control"
href="/developers/optimization/cost-control"
>
Use `run_with: code` plus `max_steps` and engine tiers to manage costs.
</Card>
<Card
title="Scheduling workflows"
href="/cloud/building-workflows/scheduling"
>
Run cached workflows on a cron schedule.
</Card>
<Card
title="Reliability tips"
href="/developers/going-to-production/reliability-tips"
>
Keep cached runs stable as target sites evolve.
</Card>
<Card
title="Run from code"
href="/cloud/building-workflows/run-from-code"
>
Trigger and monitor cached workflows from your own code.
</Card>
</CardGroup>

View file

@ -0,0 +1,62 @@
---
title: Proxy & GEO Targeting
subtitle: Route browser traffic through residential IPs in 21 countries
description: Skyvern routes browser traffic through residential proxies in 21 countries, with city- and state-level targeting in the US. Use it to access region-locked content, test geo-specific experiences, and reduce bot detection risk.
slug: developers/features/proxy-and-geo-targeting
icon: globe
keywords:
- proxy
- geolocation
- residential proxy
- RESIDENTIAL
- RESIDENTIAL_ISP
- GeoTarget
- geo-targeting
- country
- city
---
Skyvern routes browser traffic through residential proxies so every run looks like it's coming from a real consumer ISP in the country you choose. Locale and timezone auto-match the proxy region, so you never end up with a mismatched fingerprint that gives the automation away.
## Coverage
21 countries of residential coverage spanning the Americas (US, CA, MX, AR, BR), Europe (GB, IE, NL, DE, FR, ES, IT, TR), Asia (IN, PH, KR, JP, SA), Africa (ZA), and Oceania (AU, NZ).
For services that require a stable IP across a session, `RESIDENTIAL_ISP` provides a static ISP address instead of a rotating one. In the United States, you can target down to city and state level using `GeoTarget`, for example `{"country": "US", "subdivision": "CA", "city": "San Francisco"}`.
## How it's applied
**Per task:** pass `proxy_location` in the run request. **Per workflow:** set a default on the workflow and override on any individual run. **Per session:** lock a proxy to a [browser session](/developers/optimization/browser-sessions) so every operation in that session shares the same IP.
## When to use it
Region-locked pricing, inventory, or UX becomes visible when you route through the right country. Regulatory filings that require a local IP can be submitted from inside the target jurisdiction. Residential IPs also help with bot detection since they look like real consumer traffic rather than a datacenter. And `RESIDENTIAL_ISP` keeps the same IP for a full session, which matters for services that track IP changes mid-flow.
## Learn more
<CardGroup cols={2}>
<Card
title="Proxy & geolocation guide"
href="/developers/going-to-production/proxy-geolocation"
>
Full country list, `proxy_location` values, and `GeoTarget` examples.
</Card>
<Card
title="CAPTCHA & bot bypass"
href="/developers/features/captcha-and-bot-bypass"
>
Pair residential proxies with stealth for sensitive sites.
</Card>
<Card
title="Browser sessions"
href="/developers/optimization/browser-sessions"
>
Lock a proxy location across multiple operations in one session.
</Card>
<Card
title="Self-hosted proxy"
href="/developers/self-hosted/proxy"
>
Bring your own proxy on self-hosted deployments.
</Card>
</CardGroup>