Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Browser Use Public API v4, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fbrowser-use.com%2Fbrowser-use" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fbrowser-use.com%2Fbrowser-use" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with Browser Use Public API v4 API.
Start an automated browser run and track its status and output
Open and manage cloud browser sessions
List a browser's downloads and reuse saved browser profiles
Store files and workspaces that runs can read from
Connect third-party integration providers for a run
GET STARTED
Install browser extensions into a session
Patterns agents use Browser Use Public API v4 API for, with concrete tasks.
★ Agent-Driven Browser Automation
An AI agent connected through Jentic starts a browser run toward a goal, polls its status, and reads back the output and any attachments, so the agent can complete web tasks that need a real browser without a person operating one. Saved profiles let the run reuse a logged-in state across invocations.
Start a run that opens the target site, fills the form, and return the run's final output and status
Reusable Browser Sessions and Profiles
A workflow opens a cloud browser session and attaches a saved profile so repeated runs start from a signed-in state, then manages the session lifecycle and inspects its downloads. This keeps multi-step automations stable across runs without re-authenticating each time.
Open a browser session with the saved profile, run the task, and list the files it downloaded
Files and Workspaces for Runs
A pipeline uploads files into a workspace and points runs at them, then collects each run's output attachments, so inputs and outputs live alongside the automation rather than in a separate store. Workspaces group related runs and their files together.
Upload the input CSV to a workspace, start a run that uses it, and return the run's output attachments
49 endpoints — the browser use api provisions cloud browser sessions and runs automated browser tasks on them for ai agents, then returns each run's status, output, and attachments.
METHOD
PATH
DESCRIPTION
/runs
Start a browser automation run
/runs
List browser runs
/runs/{run_id}
Get a run's details
/browsers
Open a cloud browser
/sessions
List browser sessions
/profiles
Create a reusable browser profile
/workspaces
Create a workspace for runs
/runs
Start a browser automation run
/runs
List browser runs
/runs/{run_id}
Get a run's details
/browsers
Open a cloud browser
/sessions
List browser sessions
/profiles
Create a reusable browser profile
/workspaces
Create a workspace for runs
What agents get from Jentic-routed access to this vendor.
Setup
Wiring the Browser Use API by hand means handling its API key header, managing the run, session, and browser lifecycle, and polling each run until it finishes. Through Jentic you install once, import Browser Use from the API Directory, store the key once, and your agent calls it.
Permission scoping
You choose which operations your agent may call, so you can allow starting runs and reading their status while leaving destructive operations like session or profile deletion out. The run's target site travels in the request body, so rules bound which operations run rather than which page is visited.
Credential isolation
Your Browser Use API key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'run a browser task' or 'open a browser session', and Jentic returns the matching Browser Use operation with its input schema so the agent calls the right endpoint without reading the reference docs.
Alternatives and complements available in the Jentic catalogue.
Specific to using Browser Use Public API v4 API through Jentic.
Is there a Browser Use MCP server?
You don't need an MCP server to give your agent the Browser Use API. Jentic connects it directly from the API Directory: import it, store your API key once, and your agent can start browser runs and read their output straight away, with no extra server to run and no tool definitions loaded into the agent's context.
Can I limit what my agent is allowed to do with the Browser Use API?
Yes. You choose which operations your agent may call, so you can allow starting runs and reading their status while leaving session deletion and profile removal out, and every call it makes is logged. The run's target travels in the request body, so your rules bound which operations run rather than which site is visited.
What authentication does the Browser Use API use?
The Browser Use API authenticates with an API key sent in the X-Browser-Use-Api-Key request header per its OpenAPI spec. Through Jentic the key is stored encrypted by your own instance and added to each request at call time, so it never appears in the agent's prompt or logs.
Can I reuse a logged-in browser state across runs with the Browser Use API?
Yes. You save a browser profile and attach it to a session, so repeated runs start from the same signed-in state instead of authenticating each time. The session operations let an agent open, inspect, and close those browsers as it works.
What are the rate limits for the Browser Use API?
The OpenAPI spec does not specify rate limits for the Browser Use API. For current limits and concurrency guidance, see the Browser Use documentation at https://docs.browser-use.com.
How do I run a browser task with the Browser Use API through Jentic?
Import the Browser Use API from the Jentic API Directory, then have your agent issue a request such as 'run a browser task on this site'. Jentic matches the intent to the start-run operation and returns its input schema so the agent builds a valid request, with your stored API key injected at call time. To run it on your own infrastructure, install Jentic One from its GitHub repo.
For Agents
Start cloud browser sessions and automated browser runs, track their status and output, and reuse profiles, workspaces, and files. Authenticates with an API key in a request header.
Use for: Start a browser run that completes a task on a website, Check the status of a running browser task, Open a new cloud browser session, Reuse a saved browser profile for a logged-in run
Not supported: Does not handle large-scale web crawling, proxy pool management, or structured data parsing. Use for running cloud browser sessions and automated browser tasks only.
The Browser Use API provisions cloud browser sessions and runs automated browser tasks on them for AI agents, then returns each run's status, output, and attachments. You start a run that drives a browser toward a goal, open and manage the underlying browser sessions, and reuse saved profiles, workspaces, and uploaded files across runs. Integrations connect third-party providers to a run, and extensions add custom browser capabilities to a session.
This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.
Base layer of spec validity and structural soundness.
Aggregated quality score from linter diagnostics, weighted by severity.
Percentage of `$ref` references that resolve successfully.
Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).
Structural correctness score based on schema issues using logarithmic dampening.
Clarity, completeness, and ingestion readiness for developers and tooling.
How richly the API is illustrated with examples.
Percentage of examples that conform to their schemas.
Percentage of operations with complete response definitions (success, client error, server error).
Health of API ingestion, bundling, and resolution within Jentic pipelines.
Semantic breadth, depth, and agent comprehension for AI systems.
Coverage of descriptions across API elements.
Coverage of RFC 9457 Problem Details for error responses.
Coverage, uniqueness, and casing consistency of operationIds for AI inference.
Coverage of summaries across operations/tags/info.
Functional utility, complexity comfort, and AI orchestration readiness.
Agent comfort level based on API operational and structural complexity.
Trust, risk posture, and security compliance.
Average quality of security schemes based on authentication method strength (weakest link for OAuth2).
Findability, semantic richness, and reasoning readiness.
Clarity and depth of descriptions across API elements.
Score it yourself
Every API in the directory is allowlisted, so you can re-score it with no key required.
npx @jentic/api-scorecard-cli score <openapi-url>