> ## Documentation Index
> Fetch the complete documentation index at: https://browseruse-0aece648-codex-docs-supported-exports.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> 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; V2 is the lower-cost option for simple tasks. Keep V3 examples explicitly versioned. The open-source browser-use library and hosted browser-use-sdk have different APIs.
> 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 / $200 / $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.
> Budget polling across the project: the standard general bucket is 25 requests/second, including V4 event reads and full run reads. Selected status reads have a separate higher bucket. Use bounded workers, stagger polls, respect Retry-After, and drain hasMore event pages after terminal status. A busy V4 session returns 409; its queue holds 10 pending messages and is not a project-wide batch queue.
> A completed run or closed CDP connection does not immediately stop its cloud 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; 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.

# 1Password & 2FA

> Auto-fill passwords and TOTP codes from 1Password in API tasks.

## Setup

### 1. Create a dedicated vault

Create a new vault in 1Password for Browser Use. Add the credentials you want the agent to access (usernames, passwords, and 2FA/TOTP codes).

### 2. Create a service account token

1. Go to [1Password Developer Tools - Service Accounts](https://my.1password.eu/developer-tools/active/service-accounts)
2. Click **New Service Account**, name it "Browser Use Cloud"
3. Grant **read access** to the dedicated vault
4. Copy the generated token

### 3. Connect to Browser Use Cloud

1. Go to [Browser Use Cloud Settings - Secrets](https://cloud.browser-use.com/settings?tab=secrets)
2. Click **Create Integration**
3. Paste your service account token

## Use a vault in a v4 run

Pass the vault id and the domains where its credentials may be typed. Browser Use finds the project's connected 1Password integration and makes the vault's username, password, and TOTP fields available to the run. You do not need the integration, item, or field ids.

<Warning>
  Every supported credential field in the vault is made available to the run. Use a dedicated vault containing only the accounts the agent needs.
</Warning>

```bash theme={null}
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": "Open amazon.com, log in, and check my recent orders",
    "opVaultId": "<vault-id>",
    "opVaultAllowedDomains": ["amazon.com"]
  }'
```

* `opVaultAllowedDomains` is required with `opVaultId`. Use bare hostnames; a hostname also covers its subdomains.
* Vault items become aliases based on their titles, with `_username`, `_password`, or `_bu_2fa_code` suffixes.
* Vault fields and explicit `secretBindings` share a limit of 10 bindings per run. The API returns `422` if the combined total exceeds 10.
* Vault access requires exactly one active 1Password integration on the project and is unavailable for zero-data-retention projects.

<Note>
  These fields work through the v4 REST API. The currently published Python and TypeScript SDK types do not expose them yet; use the REST request above until those clients are regenerated.
</Note>

## Bind individual fields in a v4 run

For least-privilege access, use **secret bindings** instead of exposing every credential field in a vault. Each binding names one field of one 1Password item, gives it an alias the agent can ask for, and lists the hosts where it may be typed. The value never reaches the model; the server types it into the focused field when the agent asks for the alias on an allowed domain. Bindings are run-scoped, so a follow-up run that needs the same login must send them again.

<CodeGroup>
  ```python Python theme={null}
  from browser_use_sdk.v4 import BrowserUse

  with BrowserUse() as client:
      run = client.runs.create(
          "Log into Jira and create a ticket for the Q4 release",
          secret_bindings=[
              {
                  "alias": "jira_password",
                  "source": {
                      "type": "onepassword",
                      "integrationId": "<integration id from Settings → Secrets>",
                      "vaultId": "<vault id>",
                      "itemId": "<item id>",
                      "fieldId": "password",
                  },
                  "allowedDomains": ["atlassian.net"],
              }
          ],
      )
      print(client.runs.wait_for_completion(run.id).result)
  ```

  ```typescript TypeScript theme={null}
  import { BrowserUse } from "browser-use-sdk/v4";

  const client = new BrowserUse();
  const run = await client.runs.create({
    task: "Log into Jira and create a ticket for the Q4 release",
    secretBindings: [
      {
        alias: "jira_password",
        source: {
          type: "onepassword",
          integrationId: "<integration id from Settings → Secrets>",
          vaultId: "<vault id>",
          itemId: "<item id>",
          fieldId: "password",
        },
        allowedDomains: ["atlassian.net"],
      },
    ],
  });
  ```
</CodeGroup>

* `integrationId` is the 1Password integration you connected under **Settings → Secrets**.
* `vaultId` and `itemId` are the 1Password UUIDs of the vault and item (copy them from 1Password).
* `fieldId` is the field's id, not its label: `username`, `password`, or `one-time-password` for a TOTP field, which resolves to the current code.
* `allowedDomains` are bare hostnames; a host covers its subdomains.

In the chat UI at cloud.browser-use.com both options live under **Run settings → Credentials**. **Use a whole vault** asks for the vault and the allowed sites and sends `opVaultId` + `opVaultAllowedDomains`; **Add a credential** walks vault, item, and field, takes an alias and the domains, and sends one binding. The **Agents** page has a **1Password** section with the same vault + allowed-sites pair, and its REST snippet shows the resulting request.

## Use a vault in a v2 or v3 task

<CodeGroup>
  ```python Python theme={null}
  from browser_use_sdk import AsyncBrowserUse

  client = AsyncBrowserUse()
  result = await client.run(
      "Log into my Jira account and create a new ticket",
      op_vault_id="your-vault-id",
      allowed_domains=["*.atlassian.net"],
  )
  print(result.output)
  ```

  ```typescript TypeScript theme={null}
  import { BrowserUse } from "browser-use-sdk";

  const client = new BrowserUse();
  const result = await client.run(
    "Log into my Jira account and create a new ticket",
    {
      opVaultId: "your-vault-id",
      allowedDomains: ["*.atlassian.net"],
    },
  );
  console.log(result.output);
  ```
</CodeGroup>

For SSO/OAuth redirects, include all required domains:

<CodeGroup>
  ```python Python theme={null}
  result = await client.run(
      "Log into Jira and create a ticket for the Q4 release",
      op_vault_id="your-vault-id",
      allowed_domains=["*.atlassian.net", "*.okta.com"],
  )
  ```

  ```typescript TypeScript theme={null}
  const result = await client.run(
    "Log into Jira and create a ticket for the Q4 release",
    {
      opVaultId: "your-vault-id",
      allowedDomains: ["*.atlassian.net", "*.okta.com"],
    },
  );
  ```
</CodeGroup>

## How it works

When the agent encounters a login form:

1. It identifies the service (e.g., Twitter, GitHub, LinkedIn)
2. Retrieves matching credentials from your 1Password vault
3. Fills in the username and password
4. If 2FA is required and a TOTP code is stored, it generates and enters the code automatically

<Note>
  The agent never sees your actual credentials. The actual username, password, and 2FA codes are filled in programmatically — keeping your secrets hidden from the AI model.
</Note>