The problem: your agent doesn't start with a URL

A browser agent is good at acting once it has landed on a page: reading it, clicking through it, filling it in. It's much worse at the step before that, figuring out where to land in the first place. Ask it to "find pricing pages for our top five competitors" and it has no URL to open. It only has a goal in plain language.

The default fix is to point the agent at a search engine and let it drive: open the homepage, type into the search box, wait for a JavaScript-heavy results page to render, then parse that page for links. That works, but it's the slowest and most expensive way to answer a question you don't actually care about the page for, you just want the URLs. In one recent billing cycle, 4.5 million requests to google.com passed through Browserbase's own proxies, a sign of how often agents burn a full browser session just to get a list of links.

What is a search API?

A search API is an interface that takes a plain-language query and returns a ranked list of relevant URLs, plus metadata like title and publish date, as structured data. You send a query over HTTP and get JSON back. No browser render, no results page to parse, no session to keep alive.

That's the whole job: turn "where should my agent start?" into a short, ranked list it can loop over programmatically.

Why agents need this more than a human browsing does

A person doing this same research reads a results page once, scans ten blue links, and clicks the one that looks right. An agent doing it at scale, across hundreds of queries in a workflow, needs the output in a form it can loop over: a list of URLs with titles it can rank or filter, not a page of HTML built for human eyes.

Cost matters too. Driving a full browser to a search engine means paying for a browser to boot, a page to render, and a DOM to walk, before your agent has done any of the work it actually exists to do. A dedicated search API skips all of that: no browser spins up, so there's nothing to boot or render.

How do you give your agent a search API?

Browserbase Search is a REST API, available in the TypeScript and Python SDKs, that returns structured results for a query. It uses the same `x-bb-api-key` you already use for browser sessions, so there's no separate account or key to manage.

import { Browserbase } from "@browserbasehq/sdk";

const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY! });

const response = await bb.search.web({
  query: "pricing pages for headless browser infrastructure vendors",
  numResults: 10, // up to 25 results
});

console.log(`Request ID: ${response.requestId}`);
for (const result of response.results) {
  console.log(`${result.title} - ${result.url}`);
}

from browserbase import Browserbase
import os

bb = Browserbase(api_key=os.environ["BROWSERBASE_API_KEY"])

response = bb.search.web(
    query="pricing pages for headless browser infrastructure vendors",
    num_results=10,
)

print(f"Request ID: {response.request_id}")
for result in response.results:
    print(f"{result.title} - {result.url}")

That's the whole integration. No proxies to configure, no results page to render, no headless instance to keep alive just to read a list of links.

What do you get back?

Each result is a structured object: a URL and title are always present, plus optional metadata when the source publishes it.

What does it cost, and what are the limits?

Search ships with a monthly allocation on every plan, then pay-as-you-go overage. It's rate limited to 2 requests per second per project on every plan below Scale.

Search, Fetch, or Browser: which one does your agent actually need?

Search solves exactly one problem: your agent doesn't know where to go yet. Once it has a URL, two different questions come up next, and each has its own API.

Most research or lead-generation workflows chain all three: Search to find candidate pages, Fetch to quickly rule out the irrelevant ones, and a full browser session for the pages that need real interaction. For the full breakdown with examples, see our guide on which Browserbase API to use.

Taking it to production

Search is a stateless API call, so it scales the same way the rest of your request traffic does: add retries for rate-limit and service-unavailable responses, and watch your monthly call count against your plan's allocation. When a workflow needs to run past the free tier's volume, moving to a paid plan raises the allocation and adds overage pricing rather than a hard cutoff.

Once Search hands your agent a URL, the next step is usually a browser session to act on it: logging in, clicking through, or pulling data that only renders after JavaScript runs.

Do I need a browser session to use Search?

No. Search is a lightweight API call that returns a list of URLs and metadata. It doesn't open a browser, render a page, or use any of your session concurrency.

Can I just use my model provider's built-in web search instead?

Some model providers expose their own search tool call, but that ties your results to whichever model you're running that day. A dedicated search API gives you the same interface regardless of which LLM your agent is using.

Is Browserbase Search free?

Every plan, including the free tier, includes 1,000 Search calls a month. Paid plans add overage pricing beyond that allocation instead of a hard cutoff.

What's the rate limit on Search?

2 requests per second per project on Free, Developer, and Startup plans. Scale plans get a custom limit.

How many results can I get back per query?

Between 1 and 25 per request, set with numResults. It defaults to 10 if you don't specify it.

Last updated: July 29, 2026.