> ## 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.

# Webhooks

> Receive V2 task and V3 session notifications and verify the webhook signature.

Set up webhooks at [cloud.browser-use.com/settings?tab=webhooks](https://cloud.browser-use.com/settings?tab=webhooks).

## Events

| Event                      | API       | When                                                  |
| -------------------------- | --------- | ----------------------------------------------------- |
| `agent.task.status_update` | V2        | Task status changes (`running`, `idle`, or `stopped`) |
| `session.status.update`    | V3        | Session status changes; inspect `payload.status`      |
| `test`                     | Dashboard | Webhook test ping                                     |

Match the event type to the API version you use. For V4 run monitoring, see [Observability](/cloud/agent/observability) and [polling guidance](/cloud/guides/concurrency#budget-http-requests-separately).

## Payload

A V2 task event includes `task_id`, `session_id`, `status`, and task `metadata`:

```json theme={null}
{
  "type": "agent.task.status_update",
  "timestamp": "2026-09-09T12:00:00Z",
  "payload": {
    "task_id": "task_abc123",
    "session_id": "session_xyz",
    "status": "idle",
    "metadata": {}
  }
}
```

A V3 event uses the session's `id` as `payload.session_id`. `output` is included when available:

```json theme={null}
{
  "type": "session.status.update",
  "timestamp": "2026-09-09T12:00:00Z",
  "payload": {
    "session_id": "session_xyz",
    "status": "idle",
    "output": "The agent's result"
  }
}
```

Status-change events are not all completion events. Check the status before continuing your workflow.

## Signature verification

Every webhook request includes two headers:

* `X-Browser-Use-Signature`: lowercase hexadecimal HMAC-SHA256 signature.
* `X-Browser-Use-Timestamp`: Unix timestamp in seconds when this delivery was sent.

The signed message is the UTF-8 encoding of `{header_timestamp}.{canonical_payload}`. The canonical payload is exactly Python's `json.dumps(payload, sort_keys=True, separators=(',', ':'), ensure_ascii=True)`, applied to the **entire event**, including its `type`, `timestamp`, and `payload`.

This is not a signature over the raw HTTP body. The sender serializes the HTTP body separately. Non-ASCII characters are escaped in the signed representation: for example, `München` becomes `M\u00fcnchen`.

<Warning>
  JavaScript `JSON.stringify`, even after sorting an object's keys, does not implement this format. Unicode escaping, integer-like object keys, and number formatting can differ from Python. Do not use a generic JavaScript JSON canonicalizer or raw-body HMAC verifier for this contract. The Python verifier below matches the current sender; other implementations must match its serialization exactly and preserve number representations when parsing.
</Warning>

Save this as `webhook_verify.py`:

```python theme={null}
import hashlib
import hmac
import json
import re
import time


def verify_webhook(body: bytes, signature: str, timestamp: str, secret: str) -> bool:
    if not isinstance(timestamp, str) or not re.fullmatch(r"[0-9]{1,12}", timestamp):
        return False
    if abs(time.time() - int(timestamp)) > 300:
        return False
    if not isinstance(signature, str) or not re.fullmatch(r"[0-9a-f]{64}", signature):
        return False

    try:
        payload = json.loads(body)
        if not isinstance(payload, dict):
            return False
        canonical = json.dumps(
            payload, sort_keys=True, separators=(",", ":"),
            ensure_ascii=True, allow_nan=False,
        )
    except (ValueError, TypeError, UnicodeError):
        return False

    message = f"{timestamp}.{canonical}".encode("utf-8")
    expected = hmac.new(secret.encode("utf-8"), message, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, signature)
```

The five-minute timestamp window limits replay, but does not make delivery unique. Make your business action idempotent so a duplicate callback cannot process the same result twice. Keep your server clock synchronized.

## Example: FastAPI webhook handler

Install `fastapi` and `uvicorn`, put this `app.py` beside `webhook_verify.py`, set `WEBHOOK_SECRET` to the signing secret from your webhook settings, and run `uvicorn app:app --port 3000`.

```python theme={null}
import json
import os

from fastapi import FastAPI, HTTPException, Request
from webhook_verify import verify_webhook

app = FastAPI()
WEBHOOK_SECRET = os.environ["WEBHOOK_SECRET"]


@app.post("/webhook")
async def handle_webhook(request: Request):
    body = await request.body()
    signature = request.headers.get("x-browser-use-signature", "")
    timestamp = request.headers.get("x-browser-use-timestamp", "")

    if not verify_webhook(body, signature, timestamp, WEBHOOK_SECRET):
        raise HTTPException(status_code=401, detail="Invalid webhook signature or timestamp")

    event = json.loads(body)
    if event.get("type") in {"agent.task.status_update", "session.status.update"}:
        data = event["payload"]
        # Persist or enqueue the verified event for your application to process.
        # Deduplicate before applying business side effects.
        print(f"Session {data['session_id']} is now {data['status']}")

    return {"status": "ok"}
```

Return promptly after durably accepting the event. The sender has a 10-second request timeout and retries temporary failures, so slow processing can cause duplicate deliveries. HTTP 400, 401, 403, 404, and 410 are not retried.

<Tip>
  For local development, expose your local server with a tool such as [ngrok](https://ngrok.com): `ngrok http 3000`. Set the resulting `/webhook` URL in the dashboard and use its test action before starting tasks.
</Tip>