Skip to main content
A manifest is the central artifact BrowserWire produces from a discovery session. It captures a complete, machine-readable description of what a website exposes: the objects on the page, the actions you can take, the data you can read, and the workflows that combine those actions into meaningful tasks. Your AI agent consumes the manifest (or the OpenAPI spec derived from it) to understand what a site can do and how to call it — without any manual wiring on your part.
The manifest is the source of truth for the OpenAPI spec served at /api/sites/:slug/openapi.json. Any change to the manifest is immediately reflected in the spec.

​
Sections

A manifest is organized into six top-level sections. Each section is described below.
Entities are the domain objects BrowserWire identifies on the page — things like a login form, a product card, a navigation menu, or a search bar. Each entity groups related actions and views together.An entity carries observable signals (role, text content, URL patterns, element attributes) that BrowserWire uses to reliably re-identify it across page loads. A vision LLM assigns a human-readable semanticName so the entity is meaningful to your agent.
Actions are callable operations bound to a specific entity — clicking a button, filling a field, submitting a form, selecting an option. Each action has:
  • Inputs — typed parameters the operation accepts (string, number, boolean, or enum)
  • Preconditions — guard checks that must pass before the action can run
  • Postconditions — checks that verify the action succeeded
  • Locator set — multiple targeting strategies (CSS, XPath, ARIA role, test ID) ranked by confidence, so the runtime can find the right element even if the page changes slightly
Views are structured data extraction definitions. A view describes how to read information off the page — a list of search results, a table of transactions, a product’s price and title — and maps each field to a typed value (string, number, boolean, or date).Views can be static (the data is always present) or dynamic (the data depends on prior actions or inputs).
Workflows are task-level APIs synthesized from discovered actions. A workflow chains multiple actions into a single callable operation — for example, navigating to a login page, filling in credentials, and submitting the form. See Workflows for a full explanation.
Pages group entities, actions, and views by route. Each page definition records the URL pattern it matches, along with the IDs of the views and actions that live on that route. This lets your agent reason about which operations are available at a given URL.
Errors are typed failure definitions with stable codes. Each error carries a message template and a classification:
ClassificationMeaning
recoverableThe operation can be retried or handled gracefully
fatalThe operation cannot proceed; user intervention is needed
securityA security boundary was encountered (e.g. CAPTCHA, auth wall)

​
Versioning

Every manifest carries two version fields, both following semver:
FieldPurpose
contractVersionThe version of the BrowserWire contract schema itself. Increments when the manifest format changes in a breaking way.
manifestVersionThe version of this site’s manifest. Increments automatically when BrowserWire detects changes to entities, actions, or views after re-discovery.
Your agent can use manifestVersion to detect when a site’s API has changed and decide whether to re-fetch the OpenAPI spec.
BrowserWire tracks compatibility between manifest versions and will flag breaking changes — for example, if a previously required action input is removed. You can inspect diffs via the /api/sites/:slug/manifest endpoint.

​
Example

Here is a minimal manifest for a site with a single login form: 
{
  "contractVersion": "1.0.0",
  "manifestVersion": "1.2.0",
  "metadata": {
    "id": "mf_01j9z2k",
    "site": "example-com",
    "createdAt": "2025-10-01T09:00:00Z",
    "updatedAt": "2025-10-14T11:23:00Z"
  },
  "domain": "authentication",
  "domainDescription": "A standard email/password login page with a persistent session.",
  "entities": [
    {
      "id": "ent_login_form",
      "name": "login_form",
      "semanticName": "Login Form",
      "description": "The primary authentication form on the sign-in page.",
      "signals": [
        { "kind": "role", "value": "form", "weight": 0.8 },
        { "kind": "text", "value": "Sign in", "weight": 0.6 }
      ],
      "confidence": { "score": 0.92, "level": "high" },
      "provenance": {
        "source": "agent",
        "sessionId": "sess_abc123",
        "traceIds": ["trace_001"],
        "annotationIds": [],
        "capturedAt": "2025-10-01T09:00:00Z"
      }
    }
  ],
  "actions": [
    {
      "id": "act_fill_email",
      "entityId": "ent_login_form",
      "name": "fill_email",
      "semanticName": "Fill email address",
      "inputs": [
        { "name": "email", "type": "string", "required": true, "description": "The user's email address" }
      ],
      "preconditions": [],
      "postconditions": [],
      "recipeRef": "recipe://login/fill_email/v1",
      "locatorSet": {
        "id": "ls_email_input",
        "strategies": [
          { "kind": "role_name", "value": "textbox:Email", "confidence": 0.95 },
          { "kind": "css", "value": "input[type='email']", "confidence": 0.80 }
        ]
      },
      "errors": [],
      "confidence": { "score": 0.95, "level": "high" },
      "provenance": {
        "source": "agent",
        "sessionId": "sess_abc123",
        "traceIds": ["trace_001"],
        "annotationIds": [],
        "capturedAt": "2025-10-01T09:00:00Z"
      }
    }
  ],
  "views": [],
  "pages": [
    {
      "id": "page_login",
      "routePattern": "/login",
      "name": "login_page",
      "description": "The sign-in page.",
      "viewIds": [],
      "actionIds": ["act_fill_email"]
    }
  ],
  "workflowActions": [],
  "errors": []
}

​
Relationship to the OpenAPI spec

BrowserWire generates an OpenAPI 3.0 spec directly from the manifest. Every workflow becomes a POST endpoint, every view becomes a GET endpoint, and every action schema maps to a request body or query parameter definition. You can fetch the spec at any time: 
curl http://localhost:8787/api/sites/example-com/openapi.json
Point your agent at this URL and it can discover and call every available operation without any additional configuration.