A web search API built for RAG pipelines
Ground your LLM in fresh, real-world sources. BestSearch exposes the same Tavily /search and /extract endpoints — ranked results and clean page text — with identical request params and response shapes, at half the price. Migrate retrieval in one line.
/retrieval-flow
From query to grounded answer in two calls
A retrieval-augmented-generation pipeline needs two things from the live web: the right pages, and the clean text inside them. /search handles ranking; /extract handles content.
Retrieve ranked results
Send the user question and get back scored, deduplicated results with titles, URLs and short content snippets — already ordered by relevance so your retriever has clean candidates instead of raw HTML.
Pull full page content
Take the top URLs from /search and fetch the full, parsed page body — boilerplate stripped, ready to chunk and embed. No headless browser or readability library to maintain.
Ground the generation
Chunk, embed and pass the extracted passages into your prompt as context. Same response fields as Tavily, so your existing chunking and citation code keeps working unchanged.
/example
Search, then extract
Two requests are all your retriever needs. /search returns relevance-scored results; /extract returns the full, parsed page body for the URLs you choose to keep.
- Set search_depth to advanced for deeper retrieval coverage.
- Pass the top URLs to /extract; chunk and embed the returned text.
- Response fields match Tavily — existing chunkers and citations just work.
# 1. Retrieve ranked results for the user question
curl -s https://app.websearchapi.tech/search \
-H "Authorization: Bearer $BESTSEARCH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"query": "latest changes to the EU AI Act timeline",
"search_depth": "advanced",
"max_results": 5
}'
# 2. Pull full, clean page content for the top URLs to chunk + embed
curl -s https://app.websearchapi.tech/extract \
-H "Authorization: Bearer $BESTSEARCH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"urls": ["https://example.com/eu-ai-act-update"]
}'
# Same paths, params and response fields as Tavily —
# migrating is one line: swap the base URL./parity
Identical to Tavily, where it counts
Your retrieval layer does not need to know it switched. Same endpoints, same params, same shapes, same credit model — just a lower bill.
| Capability | Tavily | BestSearch |
|---|---|---|
| Endpoints | /search · /extract · /crawl · /map · /research | Identical paths, 1:1 |
| Request params | search_depth, include_raw_content, max_results… | Same names, same defaults |
| Response shapes | results[], score, raw_content, answer… | Byte-for-byte compatible |
| Credit model | Tavily credits per call | Same credit accounting |
| Migration | — | Change the base URL only |
| Price per credit | $0.008 | $0.004 (half) |
Endpoints exposed 1:1: /search · /extract · /crawl · /map · /research
/economics
Half-price compounds when RAG fans out
Modern RAG rarely issues a single search. Query rewriting, multi-query retrieval, sub-question decomposition and agentic loops can fire 3–10 searches per user request. Each one is billed in credits — so the per-credit price is the lever on your whole retrieval bill.
At $0.004 per credit instead of Tavily's $0.008, every retrieval costs half as much. The more your pipeline fans out, the more you save.
Per credit
$0.004
vs Tavily $0.008 — a flat 50% cut on the same credit model.
5 queries / request
50% less
A multi-query retrieval step that fans out five searches halves its cost, line for line.
No lock-in tax
Same SDK calls, same JSON, one base URL. If retrieval volume drops, so does your spend — there is nothing to re-architect to capture the saving.
/faq
Questions about RAG retrieval
Why use a web search API for RAG instead of scraping myself?
A web search API gives you ranked, deduplicated results and clean extracted text in two calls — no crawler infrastructure, proxy rotation, or HTML parsing to maintain. /search returns relevance-scored candidates and /extract returns boilerplate-free page content, both shaped exactly like Tavily, so they drop straight into a retrieval-augmented-generation pipeline.
How do /search and /extract work together in a RAG flow?
Call /search with the user question to get the most relevant URLs and snippets, then pass the top URLs to /extract to pull full page bodies. Chunk and embed that text, then feed it to your LLM as grounding context. The responses use the same fields as Tavily, so your retriever, chunker and citation logic need no changes.
Is it really a drop-in Tavily replacement?
Yes. Endpoints, request parameters, response shapes and the credit model are identical to Tavily. Migration is one line: point your client base URL at https://app.websearchapi.tech and use a BestSearch key. Existing RAG code keeps running with no rewrites.
Does half the price actually matter for RAG?
RAG workloads fan out — multi-query retrieval, query rewriting, sub-question decomposition and agentic loops can fire many searches per user request. At $0.004 per credit versus Tavily's $0.008, every retrieval costs half as much, so the saving compounds with each extra query you issue.
Ground your RAG pipeline for half the price
Keep your Tavily-shaped /search and /extract code exactly as it is. Repoint the base URL to BestSearch and cut every retrieval cost in half.