Does ChatGPT browse the web by default?

Yes for paid users in the ChatGPT app. The model decides when to invoke browse based on the query. The behavior is controlled by OpenAI and not configurable from outside. For products built on the API, web search is available through the Responses API as a server tool you opt into.

Custom GPTs vs Actions vs the API – which do I want?

Custom GPTs live inside ChatGPT and let users discover them through the GPT Store. Actions are how a Custom GPT calls your backend (an OpenAPI spec, your auth, your data). The Assistants and Responses APIs are how you build a product on top of OpenAI's models from scratch, with full control over tools and conversation state. Custom GPTs are for distribution inside ChatGPT; the API is for embedding the model in your own product.

Can a Custom GPT call a search API?

Yes, by defining an Action that points at the search provider's OpenAPI spec or at your own thin wrapper around it. Tavily, Serper.dev, and SerpApi all publish OpenAPI definitions that drop into a Custom GPT's Action config. The model decides when to call the action; the result comes back as structured JSON the model can cite.

Why would I use a third-party search API when ChatGPT can browse?

Three reasons. First, the built-in browse is a black box – you cannot inspect the index, exclude domains, or bias toward sources you trust. Second, for a product built on the API, a dedicated search provider is usually cheaper per query at sustained volume. Third, latency is more predictable when you control the provider, which matters for agentic workflows where search is in the inner loop.

How do I add scraping (real browser, JS rendering) to ChatGPT?

ChatGPT itself does not run a browser for you. To add real-browser capabilities, expose a third-party browser-automation API as a tool: Browserbase, Hyperbrowser, or a scraping API like Firecrawl or Scrapfly that handles rendering server-side. The model calls the tool, the tool runs the browser, results come back as text or structured data.

Connect ChatGPT to Web Data – Integration Paths and Tools (2026)

ChatGPT and the OpenAI platform expose multiple distinct surfaces for connecting AI to web data: ChatGPT itself (with its built-in browse tool), Custom GPTs with Actions, the Responses API with its server-side web search, and the Assistants API with function calling. Each is the right answer for a different shape of product. This guide covers the trade-offs and the tools we recommend for each path.

Where you are building

The decision tree starts with which surface your product lives on.

ChatGPT (consumer) has built-in browse for paid users. If your goal is to write a prompt that makes ChatGPT a better assistant for you personally, the integration question is moot – it already browses. This is not what builders integrate against.

Custom GPTs are a distribution surface. You configure a system prompt, optionally upload knowledge files, and define Actions that call external APIs. Anyone can use the GPT inside ChatGPT. This is the right path when your audience already lives in ChatGPT and you want to be discoverable through the GPT Store.

Responses API is OpenAI's current primary API for building products. It supports server tools (web_search, file_search, code interpreter), function calling for your own tools, and stateful conversations. This is where most AI products are built today.

Assistants API is the older, soon-to-be-superseded interface that pairs threads with assistants and tools. New builds should target the Responses API; existing Assistants integrations remain supported but the platform is consolidating around Responses.

Path 1: built-in web search (Responses API)

The Responses API exposes a web_search server tool. You enable it in the request, the model decides when to call it, and OpenAI returns search results that the model cites. No external integration required.

This is the simplest path and the right starting point. Latency is good, citations are returned with the response, and you do not need to bring your own search infrastructure. Trade-offs are the same as Anthropic's first-party tool: the index is not yours to inspect or filter, source bias is not configurable, and at sustained volume a dedicated provider is usually cheaper per query.

For prototypes, internal tools, and most consumer-facing AI products, leave web_search on and ship.

Path 2: third-party search via function calling

The next step is defining a custom function the model can call, where the function calls a search provider and returns results. This pattern lets you choose the provider, control the source mix, and meter the cost.

Tavily is the default recommendation. Built for LLM grounding, simple per-query pricing, structured citation output that maps cleanly into ChatGPT's tool-output format. Tavily publishes an OpenAPI spec, so wiring it as a function or a Custom GPT Action is a few minutes of work.

SerpApi is the broadest SERP API. If your queries are best answered by Google search results (rather than a curated AI-grounding index), SerpApi parses the SERP cleanly across Search, News, Images, Maps, Shopping, and Scholar. Pricing is per query.

Serper.dev is the budget alternative for Google-only workloads. Single engine, simpler API, typically 30 to 50 percent cheaper than SerpApi at comparable volumes.

Brave Search API is the independent-index option. Brave runs its own crawl, so the result mix differs from Google or Bing – occasionally an advantage, occasionally a liability, depending on what you need to find.

The function-calling pattern looks the same across providers: you give the model a function schema (web_search(query, num_results)), the model decides when to call it, your handler calls the provider, results return as JSON, the model cites them.

Path 3: Custom GPTs with Actions

Custom GPTs are configured inside ChatGPT and call out to external services through Actions. An Action is essentially an OpenAPI spec the GPT can call.

The standard recipe for adding live web data to a Custom GPT:

Pick a search provider with a public OpenAPI spec (Tavily, Serper.dev, SerpApi all qualify) or write a thin wrapper around any provider.
Configure the Action with the provider's URL and your API key in the Action's auth section.
Adjust the GPT's instructions to describe when the Action should be used.

This works well for narrow, focused GPTs – a research assistant for a specific niche, a competitive-monitoring GPT for a particular industry, a documentation lookup GPT for a product. It does not work well for general-purpose chat products, because Custom GPTs cannot maintain stateful integrations the way an API-backed product can.

Path 4: extraction and full-page reads

Search returns URLs and snippets. Many AI workflows then need the full content of a specific page – a docs page to answer a technical question, a product page for a comparison, a long article to summarize. ChatGPT's built-in browse handles this for the consumer surface, but products built on the API need their own extraction tool.

Firecrawl is the standard recommendation. Single API, handles JS rendering, returns clean Markdown ready for LLM context. Search, scrape, crawl, and structured extraction all in one provider. Most production AI products that need both search and extraction use Tavily plus Firecrawl together.

Jina AI and Diffbot are alternatives. Jina is the simpler ergonomic choice for clean Markdown extraction; Diffbot is heavier-duty with structured-data parsing for specific page types (articles, products, discussions).

For sites with anti-bot defenses or login walls, route through a scraping API (Scrapfly, ZenRows) or a managed browser (Browserbase) exposed as a function the model can call.

Path 5: knowledge files and the file_search tool

Not every "web data" question is actually a web question. Many AI products work against a frozen corpus: documentation, research papers, internal knowledge bases. For these, OpenAI's file_search tool indexes uploaded files and lets the model retrieve passages on demand. No external search provider needed.

The right pattern depends on freshness. For data that changes (prices, news, market data) you want live web search. For data that does not (your product docs, your internal handbook) you want file_search. Most production AI products use both: file_search for the stable corpus, web_search or a third-party provider for live information.

Recommended setup by product type

For a consumer chat product built on the Responses API, leave the built-in web_search on and skip the integration work. Add file_search if you have a private corpus.

For a production AI assistant or agent with tight latency requirements or large query volumes, function-call into Tavily for grounding plus Firecrawl for extraction. Both are simple per-query pricing and easy to swap if a better option emerges.

For a Custom GPT distributed through the GPT Store, define one Action against Tavily or Serper.dev, write clear instructions about when the GPT should call it, and rely on the built-in browse for everything else.

For a research or analysis product that needs deep coverage of specific sites, pair Firecrawl (search and extraction) with a managed browser provider for sites that require login or interaction.

For a B2B SERP tool or SEO product built on top of ChatGPT, use SerpApi or DataForSEO directly via function calling. The built-in web search is not designed for the structured-ranking-data shape these products need.