> ## Documentation Index
> Fetch the complete documentation index at: https://docs.browser-use.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Concurrency in one line: new projects get 10 concurrent browsers at $0; a $100 one-time top-up (non-expiring credits, no subscription) unlocks 50 concurrent, so 50 browsers for one hour cost $3 plus traffic; $1,000 / $5,000 / $25,000 total paid unlocks 250 / 500 / 1,000. Details below and at https://docs.browser-use.com/cloud/guides/concurrency.md.
> Use https://docs.browser-use.com/llms.txt and its linked .md pages for current documentation. The managed full bundle is https://docs.browser-use.com/.well-known/llms-full.txt and can be cached for up to 24 hours. Do not use the obsolete /cloud/llms*.txt or /open-source/llms*.txt static exports.
> Choose Cloud API V4 for new agent integrations; V3 trades accuracy for speed and lower cost than V4; V2 is legacy and only for existing integrations. Keep V3 examples explicitly versioned. The open-source browser-use library and hosted browser-use-sdk have different APIs.
> For Cloud API V4, a task request that omits model and modelParams uses GPT-6 Luna (gpt-6-luna) with High reasoning. Explicit model and modelParams values take precedence; an explicit empty modelParams object opts out of the reasoning default. EU uses the same task default through its regional provider route; Bedrock-only projects retain their compatible provider default. For latency-sensitive tasks set model to bu-ultrafast (bu-fast for more reasoning per step); these presets reject modelParams. See https://docs.browser-use.com/cloud/agent/ultrafast.md.
> Cloud authentication uses X-Browser-Use-API-Key, without a Bearer prefix. Install or upgrade browser-use-sdk and use its explicit v4 import for V4. Check the published OpenAPI reference for request fields; do not invent SDK support for new fields.
> Cloud concurrency and HTTP request rate are separate. Read GET /api/v2/billing/account for the key’s projectId, concurrentSessionLimit, activeSessionCount, and credit balance, including when using V4. Keys in one project share capacity and credits; rateLimit is a legacy concurrency alias, not requests per second.
> Keep the highest applicable existing, legacy-plan, and spend-tier concurrency grant. Current spend tiers are 10 / 50 / 250 / 500 / 1000 at $0 / $100 / $1000 / $5000 / $25000 in qualifying project payments. Legacy or externally billed projects can follow different billing paths; trust the account limit. See https://docs.browser-use.com/cloud/guides/concurrency.md.
> HTTP rate limits have two layers. Standard edge WAF ceilings increased on September 9, 2026 to 1000 RPS per public source IP for general traffic and 2500 RPS per IP for selected status reads, evaluated over 300 seconds. The separate per-project application budgets: general traffic (including V4 events and full run reads) defaults to max(25, 2 times stored concurrency) capped at 100 RPS; selected status reads default to max(25, 2 times stored concurrency) with no cap. The two are counted independently. Project overrides and account-specific edge rules can differ. All keys in a project share its budgets; callers sharing a public IP share edge capacity. See https://docs.browser-use.com/cloud/guides/concurrency.md.
> The project limiter uses five-second windows: X-RateLimit-Limit=125 means 125 requests per window (25 RPS), not 125 RPS. Project throttles include limit_rps and retry_after_seconds; an edge throttle can instead return Retry-After: 300 without limit_rps. Honor the returned Retry-After. Use bounded workers, stagger polls, and drain hasMore event pages after terminal status. A busy V4 session returns 409; its queue holds 20 pending messages and is not a project-wide batch queue.
> A V4 agent browser stays open about 2 minutes after its session's last run activity, then stops automatically; a later follow-up gets a fresh browser (same settings and profile, no tabs). Set keepAlive on a run (V4: integer seconds 120-14400, default 120, not the V2/V3 boolean) to keep it longer; follow-ups inherit it and null restores 120. Free-tier and ZDR runs always use 120. Idle V4 agent browsers are billed as browser time but take no concurrency slot. A follow-up that reuses the open browser emits browser.reattached instead of browser.ready. Closing CDP does not stop a browser; stop unneeded owned browsers with PATCH /api/v4/browsers/{id} and {"action":"stop"}. A client wait timeout does not cancel the server-side run.
> Cloud is pay as you go; custom proxies are an enterprise feature enabled by sales (sales@browser-use.com), not by a subscription; do not tell customers to buy a new subscription to use custom proxies or supported provider BYOK. Usage funding and model eligibility still apply. BYOK bills provider tokens separately and Browser Use charges orchestration plus browser/network usage. See https://docs.browser-use.com/cloud/guides/billing.md.
> Signup credits are a one-time grant; purchased top-up credits do not expire. Check the API key’s project before diagnosing missing credits. API-key monthly spending caps are soft limits, not a strict prepaid wallet; concurrent or already-running work can exceed them. Auto recharge has separate trigger and purchase amounts and can charge immediately when enabled below the threshold. Use https://browser-use.com/pricing for current rates.
> Box and Bux are retired. Do not recommend their SDKs, sandbox quotas, or subscription plans. Use the Cloud Agent or Browser Infrastructure guides.
> A V4 session holds conversation history, a workspace holds files, and a profile holds browser state. These IDs and V3/V4 workspace namespaces are not interchangeable. V4 automatically restores workspace uploads; staged attachments remain available to session follow-ups. Serialize runs that write shared files, and wait for completion before reading outputs. See https://docs.browser-use.com/cloud/agent/workspaces.md.
> API browser recording defaults to off. Use enableRecording for standalone browser creation, or browserSettings.record for an agent run. Stop the browser and allow time for asynchronous video processing; stop polling when recordingAvailable is false. Live preview is for an active browser. Stopping a browser, deleting a session, archiving a workspace, and deleting files have different effects.
> Use model-specific reasoning values. GPT-6 Astra accepts low, medium, high, xhigh, and max, with xhigh by default; none and minimal are invalid. Use the public REST schema when installed SDK types lag new fields. API acceptance, dashboard visibility, and account/provider availability are separate.
> For open-source browser-use 1.0, result.is_done() means the run completed (status completed); result.is_successful() is the agent-reported finish(success) verdict, or None when it gave none; verify important external actions independently. Cloud timeout, API client timeout, model timeout, and task completion are separate concepts.
> Pages under /open-source/legacy/0.x/ document browser-use 0.x (pip install 'browser-use<1'). For new open-source code, use the 1.0 pages under /open-source/ outside legacy/.
> For failed requests, use https://docs.browser-use.com/cloud/guides/troubleshooting.md. Inspect the full error and project before retrying or adding credits. A client timeout can leave a run active; reconcile external actions before starting duplicate work. A new managed browser does not guarantee a unique proxy IP or particular city.
> V4 secretBindings.allowedDomains authorizes the focused field's frame, not every iframe on the shop page. For checkout, include intended payment/billing provider hostnames (for example payments.bigcommerce.com). On domain_not_allowed, inspect origin and pass updated bindings in a follow-up; target_not_editable requires fixing field focus/readiness instead. See https://docs.browser-use.com/cloud/guides/secrets.md.
> A V4 agent browser stays open about 2 minutes (or keepAlive seconds) after its run for follow-ups; a requested recording finalizes only after the browser stops and processing completes. Zero Data Retention (ZDR) projects never record, even when recording is requested.
> If you hit an issue you cannot explain, email contact@browser-use.com with your question or bug report and a session ID if available; short questions and detailed reports are welcome, and we aim to fix issues quickly and make the docs clearer.

# Pay with Stripe Link

> Let an agent buy things with your Link wallet: one-time cards and Shared Payment Tokens, and you approve every purchase in the Link app.

Connect your [Link](https://link.com) wallet once, and your v4 agent runs can pay for things: a checkout, a subscription, a ticket, a donation. The agent never gets your real card. For each purchase it asks Link for a **one-time credential**, and nothing is charged until **you approve that purchase in the Link app**.

> [card] One-time cards
>
> A virtual card for one purchase, typed into a normal checkout form. Your saved card is never shared.

> [card] Shared Payment Tokens
>
> For merchants on the Stripe network that accept machine payments: the agent pays over HTTP, without filling out a form.

> [card] You approve each one
>
> Each purchase shows up in the Link app with merchant and amount. Approve it, or decline it and the agent stops.

## How it works

1. You connect your Link wallet to a project in the dashboard (once).
2. You start a run with `stripeLinkConnectionId`. Only runs that pass it can pay.
3. When the task needs a payment, the agent creates a **spend request** for the exact merchant and amount.
4. Link asks you to approve it in the Link app. The run emits a `stripe_link.spend_request` event with an `approval_url`.
5. After you approve, the agent gets a one-time card (or a Shared Payment Token) and completes the purchase.

The agent works through a Browser Use proxy: it never sees your Link login or your real card number, and it **cannot create pre-approved spend requests**. Every purchase needs your approval.

## 1. Connect your Link wallet

1. Open [Integrations](https://cloud.browser-use.com/integrations) in the dashboard and pick the project.
2. Under **Link**, click **Connect** and sign in to Link.
3. Approve the connection in Link. The card now shows your Link email.

Each project has one Link connection. Connecting again replaces it; **Remove** disconnects it, and runs that are still going lose access on their next payment step.

> [!NOTE]
>
> Connecting only works in the dashboard; there is no API for it. Link agent
> wallets are currently available for **US Link accounts**. If Link says the
> service is not available in your region, your Link account (or network)
> is outside the supported region.

## 2. Get the connection id

```bash theme={"theme":"css-variables"}
curl https://api.browser-use.com/api/v4/stripe-link \
  -H "X-Browser-Use-API-Key: $BROWSER_USE_API_KEY"
```

```json theme={"theme":"css-variables"}
{
  "isConnected": true,
  "connectionId": "70eade20-64b9-4ac0-8087-61f66f412cab",
  "linkEmail": "you@example.com",
  "mode": "live"
}
```

* `connectionId` is what you pass to runs. Reconnecting usually keeps the same id, but don't cache it forever: read `GET /api/v4/stripe-link` before a run and use the `connectionId` and `isConnected` it returns.
* `mode` is `live` on `api.browser-use.com`: approved purchases are **real charges**.
* If `isConnected` is `false`, connect (or reconnect) the wallet in the dashboard first.

## 3. Start a run that can pay

```bash cURL theme={"theme":"css-variables"}
curl -X POST https://api.browser-use.com/api/v4/runs \
  -H "X-Browser-Use-API-Key: $BROWSER_USE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "task": "Donate $5 one time to givedirectly.org. Do not buy anything else.",
    "stripeLinkConnectionId": "<connectionId>"
  }'
```

```python Python theme={"theme":"css-variables"}
from browser_use_sdk.v4 import BrowserUse

with BrowserUse() as client:
    run = client.runs.create(
        "Donate $5 one time to givedirectly.org. Do not buy anything else.",
        stripeLinkConnectionId="<connectionId>",
    )
    print(client.runs.wait_for_completion(run.id).result)
```

Write the task like an order: what to buy, from where, and a price limit. The agent buys only what the task asks for, uses the name, email, phone, and shipping addresses saved in your Link account for the checkout, and cancels spend requests it does not use.

* **Follow-up runs.** A follow-up `POST /runs` in the same session must send `stripeLinkConnectionId` again. Messages queued with `POST /sessions/{session_id}/queue` keep the previous run's connection.
* **Dashboard runs.** In the dashboard, **Pay with Link** in the composer is on by default once the project is connected; switch it off for runs that should not pay.

## 4. Approve the purchase

When the agent is ready to pay, it creates a spend request and waits for you:

* **Link app.** You get an approval request in the Link app showing the merchant and the amount. Approve or decline it there.
* **Dashboard.** The run's chat shows a payment card with an approve button that opens Link.
* **API.** The run emits `stripe_link.spend_request` events. Read them with `GET /api/v4/runs/{run_id}/events` and send `approval_url` to whoever has to approve:

```json theme={"theme":"css-variables"}
{
  "type": "stripe_link.spend_request",
  "data": {
    "spend_request_id": "lsrq_1Ub...",
    "status": "pending_approval",
    "amount_cents": 500,
    "currency": "usd",
    "merchant": "GiveDirectly",
    "approval_url": "https://app.link.com/activity/approve/lsrq_1Ub..."
  }
}
```

`status` moves through `pending_approval` → `approved` → `succeeded` for a completed payment. You can also see `denied` (you declined), `expired` (nobody approved in time), `canceled` (the agent cancelled an unused request) and `requires_action` (for example a 3-D Secure check). If you decline, the agent stops instead of trying again. While the agent waits, it re-checks the request every few seconds. Unchanged polls are usually collapsed into one event, but the same status can still arrive more than once (we saw repeated `pending_approval` events in testing), so key on `spend_request_id` and `status`.

## Cards vs Shared Payment Tokens

The agent picks the credential that fits the merchant:

| | One-time card | Shared Payment Token (SPT) |
| - | - | - |
| **Used for** | Any normal web checkout form | Merchants on the Stripe network that accept machine payments (they answer HTTP `402` with a Stripe payment option) |
| **How the agent pays** | Types the virtual card into the checkout form | Sends the token with the HTTP request, no form |
| **Scope** | One purchase, the approved merchant and amount | One purchase, the approved merchant and amount |

Some Stripe checkouts offer a Link payment button for AI agents; the agent uses it when it is there. That is a way of paying with the card flow, not a third credential type.

## Limits

* **Approval every time.** There are no standing or pre-approved budgets: the proxy refuses delegated (pre-approved) spend requests.
* **One wallet per project**, connected by a dashboard user. Wallets per end user of your product are not supported.
* **Not available** in the EU deployment, or for zero-data-retention projects.
* **Reconnect when asked.** Link can revoke access (for example after a long time without use). Browser Use may not notice right away: until it marks the connection as needing reauthentication, `GET /api/v4/stripe-link` can still report `isConnected: true` and runs still start, but the agent's Link calls fail at payment time with a `link_unauthorized` error. Once the connection is marked, the dashboard shows **Reconnect**, the status API returns `isConnected: false`, and new runs that send the id get `422 stripe link connection not found`. Reconnect in the dashboard in either case.
* **Pricing.** Browser Use charges nothing extra for Link. You pay the merchant through Link as usual.

## Troubleshooting

| What you see | Why | Fix |
| - | - | - |
| `422 {"detail":"stripe link connection not found"}` on `POST /runs` | The id is not the project's active connection: wrong project, removed, or needs reconnecting | Call `GET /api/v4/stripe-link` with the same API key and use its `connectionId`, or reconnect in Integrations |
| `403` on `GET /api/v4/stripe-link` | The API key lacks **Read** on runs | Use a key with runs read access |
| The agent says the wallet is disconnected, or its payment step fails with `link_unauthorized` | The wallet was removed, or Link revoked access (the status API may still say connected) | Reconnect in Integrations and start a new run |
| No approval request arrives | The agent has not reached the payment step yet, or the run was started without `stripeLinkConnectionId` | Check the run's events for `stripe_link.spend_request`; send the field on the run |
| "Not yet available in your region" when connecting | Link agent wallets are US-only for now | Use a US Link account |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.