How to migrate from Tavily in one line

If you already ship code against Tavily's web search API, you do not need a rewrite to cut your bill. BestSearch is fully Tavily-compatible: the same endpoints, the same request parameters, the same JSON response shape, and the same credit model. To migrate from Tavily you change exactly one thing — the base URL — and everything downstream keeps working. The only difference you will notice is the invoice: $0.004 per credit instead of $0.008.

This is a practical how-to. We'll show the single line you change, a before/after curl, what stays identical, how to handle your API key, how to verify the switch, and how to roll back if you ever want to. No lock-in, no migration sprint.

The one line you change to migrate from Tavily

Almost every integration reads its host from a single environment variable or client config field. Repoint it from Tavily's host to BestSearch and you are done:

# Before — Tavily
BASE_URL=https://api.tavily.com

# After — BestSearch (everything else stays the same)
BASE_URL=https://app.websearchapi.tech

That is the entire migration. No new request builders, no response remapping, no schema translation layer. If your code points at a hardcoded URL instead of a variable, find-and-replace api.tavily.com with app.websearchapi.tech and commit.

Before and after: a real request

Here is a typical Tavily search call:

curl https://api.tavily.com/search \
  -H "Authorization: Bearer $TAVILY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"latest on retrieval augmented generation","max_results":5}'

And the same call against BestSearch — identical method, headers, path, and body. Only the host (and your key) differ:

curl https://app.websearchapi.tech/search \
  -H "Authorization: Bearer $BESTSEARCH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"latest on retrieval augmented generation","max_results":5}'

The response you get back has the same fields in the same places, so any parsing or scoring logic you already wrote stays valid.

What stays identical

Compatibility is the whole point, so the surface you depend on does not move:

• Endpoints — all five are exposed 1:1: /search /extract /crawl /map /research.
• Request parameters — fields like query, max_results, search_depth, include_domains and the rest behave the same way.
• Response shape — the JSON keys and nesting match, so your deserialization code is untouched.
• Credit model — the same credit accounting Tavily uses, just priced at half per credit.

Because nothing about the contract changes, an existing test suite is the cleanest way to validate the move. Run it against the new host before the old one.

Keep your API key handling as-is

Authentication works the same way: a bearer token in the Authorization header. Issue a key from the BestSearch dashboard, drop it into the same secret store or environment variable you already use, and leave your auth code alone. If your stack uses the official Tavily SDK, you usually only set the base URL on the client:

# Python (tavily-python) — point the client at the new host
from tavily import TavilyClient

client = TavilyClient(
    api_key=os.environ["BESTSEARCH_API_KEY"],
    api_base_url="https://app.websearchapi.tech",
)

resp = client.search("latest on retrieval augmented generation", max_results=5)

Keep your old Tavily key around until you have verified everything — there is no reason to delete it during the cutover.

Edge cases worth a second look

Most migrations are genuinely a one-line change, but it is honest to flag the handful of spots where any cutover deserves a glance:

• Hardcoded hosts. If the Tavily host appears in more than one place — a worker, a cron job, a serverless function — make sure every copy is repointed, not just the main service.
• Retry and timeout config. These live in your HTTP client, not the API, so they carry over unchanged. There is nothing to re-tune, but it is worth confirming your client points at the new host.
• Allowlists and egress rules. If your network restricts outbound calls by domain, add app.websearchapi.tech to the allowlist before you flip traffic.
• Logging and metrics. Dashboards that key off the upstream hostname will start reporting the new host — expected, but good to know so an alert does not surprise you.

None of these touch your request or response code. They are operational details, and most teams hit none of them.

Migrate gradually if you prefer

You do not have to flip everything at once. Because the base URL is just config, you can route a percentage of traffic — or a single non-critical job — to BestSearch first, compare results against Tavily, and widen the rollout as confidence grows. A feature flag or environment-specific variable is enough; no parallel code path is required since the request and response contracts are identical.

Verify the switch

A quick checklist to confirm the migration landed:

• Send one /search request and confirm you get a 200 with results in the expected fields.
• Diff a response against a saved Tavily response — same keys, same structure.
• Exercise any other endpoints you actually use (/extract, /crawl, /map, /research).
• Watch credit usage in the dashboard to confirm billing is what you expect.
• Run your integration tests; they should pass without edits.

If you want the full parameter and field reference while you test, the API docs mirror the endpoints you already know.

You can switch back anytime

Because the only thing you changed is the base URL, rollback is symmetric: point the variable back at api.tavily.com and you are exactly where you started. There is no proprietary format to unwind and no data to export. That makes trying BestSearch low-risk — run it in staging, compare results, and keep it only if you like what you see. For a fuller side-by-side, see our Tavily alternative overview, or check the numbers on the pricing page.

The cost difference

The compatibility is free; the savings are the reason to bother. At $0.004 per credit versus Tavily's $0.008, identical traffic costs half as much. A one-line change that halves a recurring API bill is about as good as migrations get.