Search API Failover: Production Pattern (2026)
With SerpAPI in litigation and Sonar reporting credit wipes, multi-vendor failover is non-optional. Try-catch-rotate pattern with vendor attribution logging. Implementation included.
With SerpAPI in litigation and Sonar API reporting credit wipes, the 2026 search API market has a new risk profile. Production teams are building multi-vendor failover patterns. Here is the concrete implementation.
The failover pattern
Try primary vendor with a 5-second timeout. On failure (timeout, 5xx, rate limit), try secondary. On double failure, try tertiary. Log which vendor served each request for cost tracking and reliability metrics. The caller sees a unified response shape regardless of which vendor served it.
import requests, os, time, logging
log = logging.getLogger("search")
VENDORS = [
{"name": "scavio",
"url": "https://api.scavio.dev/api/v1/search",
"headers": {"x-api-key": os.environ.get("SCAVIO_API_KEY", "")},
"build_body": lambda q: {"query": q, "platform": "google", "limit": 10}},
{"name": "serper",
"url": "https://google.serper.dev/search",
"headers": {"X-API-KEY": os.environ.get("SERPER_KEY", "")},
"build_body": lambda q: {"q": q}},
{"name": "brave",
"url": "https://api.search.brave.com/res/v1/web/search",
"headers": {"X-Subscription-Token": os.environ.get("BRAVE_KEY", "")},
"build_body": lambda q: {"q": q}},
]
def search_with_failover(query: str, timeout: int = 5) -> dict:
for vendor in VENDORS:
try:
start = time.time()
resp = requests.post(vendor["url"],
headers={**vendor["headers"], "Content-Type": "application/json"},
json=vendor["build_body"](query), timeout=timeout)
resp.raise_for_status()
latency = time.time() - start
log.info(f"{vendor['name']} served in {latency:.2f}s")
return {"vendor": vendor["name"], "latency": latency,
"data": resp.json()}
except Exception as e:
log.warning(f"{vendor['name']} failed: {e}")
raise RuntimeError("All search vendors failed")Vendor selection criteria
- Primary: multi-platform, MCP support, credit-based pricing
- Secondary: cheapest per-query cost for Google-only fallback
- Tertiary: independent index (not Google-dependent) for true redundancy
Monitoring and alerting
Track per-vendor success rate, P50/P99 latency, and failover frequency. Alert when the primary vendor's failure rate exceeds 1% over a 1-hour window. Alert when failover to tertiary occurs at all — that means two vendors are degraded.
Cost implications
Multi-vendor failover costs nothing extra when the primary vendor is healthy. You only pay the secondary vendor's per-query cost during failover events. Budget for 2-5% failover traffic as a baseline. The insurance cost is negligible compared to the downtime cost of a single-vendor outage.