Tavily supplies web search and extraction for AI applications

Tavily supplies web search and content retrieval APIs for applications that need information beyond a model’s stored knowledge. Developers can search for relevant sources, extract selected pages, discover a site’s URLs or crawl a bounded part of it. The practical value is a controllable research pipeline: an application can decide what to search, what to read and how to connect evidence to its answer.

01 / ProductWhat Tavily provides to a research application

Tavily’s core retrieval tools serve different jobs. Search¹ discovers sources for a query and returns ranked results. Extract² retrieves content from specified URLs. Map³ discovers links within a site. Crawl⁴ combines site navigation with content retrieval. Choosing between them changes both the work performed and what the application must decide itself.

A simple question-answering application may search and generate a response immediately. A more exacting workflow may first identify likely official pages, select a small subset, extract their contents and then verify each proposed claim. The second design has more explicit stages, but it also creates places to inspect missing evidence and contradictory sources.

Tavily should therefore be understood as infrastructure within an information product. A search response is an input to that product. Its usefulness depends on how the application interprets the question, selects sources, handles failed retrieval and presents uncertainty. A convenient content API does not by itself establish that a statement is accurate, complete or appropriate for the reader’s decision.

02 / AudienceWho should use Tavily

Tavily is relevant to developers building public-web research, company enrichment, monitoring and answers that need recent supporting material. It is especially useful when the application needs to control the sources and retain their URLs rather than merely accept a generated summary from another interface. Technical teams can build those controls around the API responses.

A good use case has a defined evidence standard. For a software directory, the official pricing page may be authoritative for plan prices while the documentation explains feature limitations. For a public-company profile, an announcement and a later correction may both matter. The application needs an explicit way to represent those relationships instead of merging every retrieved passage into one undifferentiated context.

An individual who occasionally wants a researched answer may prefer an existing research interface. Tavily becomes more compelling when retrieval is a repeatable feature inside a product or business workflow. The relevant comparison then includes implementation effort, observability, source coverage and cost per usable output.

It also serves a different boundary from Glean’s enterprise knowledge platform. Glean connects internal company systems with their identities and permissions; Tavily’s APIs focus on web retrieval. Finding an employer’s public help page is different from finding a private support escalation. Choose the retrieval foundation according to where the required evidence actually lives.

03 / WorkflowA worked software company research workflow

Consider an illustrative application that maintains factual software company profiles. It needs the current product description, pricing basis and implementation limitations for each company, supported by primary sources. The following design is a proposed workflow, not a report of benchmark testing or an automated publishing system we operated.

Begin with a verified company domain and an explicit research question. Divide the job into product, pricing, documentation and usage constraints. Tavily’s search guidance⁵ recommends focused queries rather than a single oversized prompt spanning several topics. In this example, separate queries also make missing coverage visible: five product results do not compensate for a missing pricing source.

Use source restrictions deliberately. The Search API¹ distinguishes a domain filter, which limits results to selected domains, from boosting those domains while allowing others. That difference matters for primary-source research. A boosted vendor domain can still return an external review; the application should not label that result official merely because the domain was favored.

Discover first, then retrieve the pages that matter

If the documentation structure is unfamiliar, use Map³ to discover candidate paths with depth, breadth and overall limits. Mapping returns URLs, which still need inspection. A path containing “pricing” may be an old announcement rather than the current commercial page. Select the relevant pages before spending effort extracting everything the site exposes.

For the selected URLs, use Extract to retrieve content. Tavily’s extraction guidance⁶ explains the choice between direct extraction of curated URLs and requesting raw content with search results. It also supports query-focused chunks. For a price table, however, a short relevant excerpt may omit the annual-billing note or the row that defines the usage allowance.

The proposed application should retain both the extracted passage and enough surrounding context to interpret it. Store the source URL, retrieval time, claimed billing period and the fact the passage supports. If the commercial page is unavailable, leave the price unresolved instead of substituting an older search snippet without identifying its age.

Crawl is useful when the job truly needs a collection, such as the current integration documentation for a product. Its API controls⁴ include path and domain selection, exclusions and a total page limit. In this example, constrain it to the relevant documentation area. A successful crawl of an entire blog archive can be expensive and still fail to answer the integration question.

Build the article from claims and supporting evidence

After retrieval, create a small claim ledger: what the company does, who the documented feature serves, what the price covers and which limitations change the buying decision. Each factual claim should point to an actual passage. Original analysis, such as how a workflow might be designed, should be marked as analysis rather than presented as a vendor guarantee.

Have the application identify disagreements explicitly. A homepage might call a feature generally available while a detailed setup guide identifies an account requirement. The appropriate output is the qualified capability, with the relevant source. Returning a greater number of pages cannot resolve that conflict without interpretation.

Treat retrieved pages as evidence, not instructions to the research agent. A page can contain unrelated prompts, navigation text or malicious directions. Its content should not acquire authority to change the task, expose application credentials or publish the result. This separation belongs in the application’s design, regardless of which search provider supplies the text.

04 / PricingTavily pricing and an illustrative cost calculation

Tavily’s credit pricing⁷ includes a free monthly allowance, metered use and monthly packages. The table lists the published US-dollar figures at the research date. A credit is a billing unit whose consumption depends on the endpoint and configuration; it is not a universal synonym for one completed research report.

The same credit guide prices basic search at one credit and advanced search at two. Basic extraction costs one credit per five successful URL extractions; advanced extraction costs two. Mapping costs one credit per ten successful pages, or two with instructions, while crawling combines mapping and extraction charges. These distinctions should be visible in an application’s cost records.

For illustrative arithmetic, 100 basic searches consume 100 credits. At the pay-as-you-go rate of US$0.008 per credit, that search component costs US$0.80. If the workflow then performs 500 successful basic URL extractions, that adds 100 credits, bringing those two components to US$1.60. This excludes other requests, model generation, storage and the effect of included allowances; it is a usage example, not a promised cost per 100 profiles.

A less obvious cost choice is automatic parameter selection. Tavily’s Search reference¹ says this can select advanced depth and therefore the two-credit rate, while explicit settings override automatic choices. A production application should record the effective settings and usage, particularly when comparing two retrieval strategies.

05 / DistinctionsWhat stands out in Tavily’s approach

The combination of discovery and extraction gives developers several useful stopping points. An application can stop after finding an authoritative URL, read only selected pages or expand to a bounded site crawl when the task requires it. That composability is valuable when different questions need different amounts of evidence.

Content shape is another practical decision. Tavily’s search best practices⁵ distinguish query-relevant chunks from a general page summary and describe depth as a latency-versus-coverage choice. Those are vendor descriptions, not benchmark results from this profile. A product team should compare the modes using questions its users actually ask, including obscure and recently changed facts.

Exa’s web search approach is a relevant alternative for programmable discovery and retrieval. Compare the two on source coverage, extraction completeness and useful evidence returned for the same task. Counting results or comparing a single query’s speed misses the cost of the follow-up work needed to produce a defensible answer.

The company-profile example illustrates why the most useful metric may be supported claims per completed profile. A slower search that finds the correct implementation guide can reduce later research. Conversely, a broad response filled with plausible but outdated pages can increase review effort even if the initial API call was fast.

06 / QuestionsQuestions to resolve before production use

How will the application interpret dates?

The Search API’s date fields¹ distinguish detected publication information from date filtering. The returned date can represent an update, and undated pages are treated differently when strict filtering is enabled. A displayed date should therefore be checked against the source when the distinction changes the answer.

For the software directory, an undated current price page may be more useful than a clearly dated announcement from last year. Keep retrieval time separately from the source’s publication or update date. This makes later revision possible without pretending the moment a page was fetched is the moment its claims became true.

What happens when retrieval is incomplete?

The Extract response² includes failed results, and extraction depth trades additional retrieval work against latency and cost. An application should preserve those failures alongside successful pages. If the pricing source fails while product pages succeed, the report is incomplete in a specific way; it is not evidence that pricing is unavailable everywhere.

Tavily’s rate limits⁸ distinguish development and production keys, with default limits of 100 and 1,000 requests per minute respectively. Crawl has a separate 100-request limit for both. The documentation provides a retry-after header for rate-limit responses. Schedule batches and handle that signal rather than repeatedly resubmitting the same work immediately.

Keep a durable record of requested, retrieved and reviewed sources. That record lets a later run fill gaps instead of repeating every successful call. It also makes an answer explainable when a source changes between research and publication. Reliable research infrastructure includes both successful retrieval and an honest account of what remains unknown.

07 / DecisionDeciding whether to build with Tavily

Tavily is a strong candidate when a product needs programmable access to public-web evidence and the team wants control over discovery, extraction and source selection. Start with a small collection of real research tasks and compare the resulting evidence, missing material, latency and complete cost.

Its APIs can simplify retrieval; the application still needs an evidence policy and an output that readers can inspect. The best implementation makes those responsibilities explicit. Build around a useful, supported result, then choose the smallest retrieval sequence that consistently supplies the information required to produce it.