OpenWebSearch - unified search API gateway

TL;DR

TL;DR: OpenWebSearch is a search API gateway that routes one request format across multiple search providers (Exa, Brave, Perplexity, Parallel, Valyu, and more), returning every result in a normalized shape — with automatic fallback when a provider fails.

Source and Accuracy Notes

⚠️ This section is MANDATORY. All links must be verified from actual source, not guessed.

• Project page: openwebsearch.ai — verified via direct fetch
• Source repository: github.com/JigsawStack — verified via page footer
• License: not verified (no LICENSE file found in repo or documentation)
• HN launch thread: news.ycombinator.com/item?id=42281873
• Source last checked: 2026-08-19

What Is OpenWebSearch?

Integrating multiple search providers means separate API keys, client libraries, and response parsers for every index you want to query. OpenWebSearch collapses that surface into a single REST endpoint: one key, one request shape, and one normalized response that works the same way regardless of which provider handled the query.

The product is built by Interfaze and sits alongside their web scraping API under the same account. The GitHub organization is JigsawStack.

Supported providers

Currently available: Exa, Brave, Perplexity, Parallel, Apify Serp, Valyu.

Coming soon: Tavily, Bing, Octen.

Providers are selectable per-request through an ordered list. If the first provider fails or degrades, the request falls through to the next one automatically.

Setup Workflow

Step 1: Add credits

OpenWebSearch uses a prepaid credit system. You buy credits once and spend them across any provider — no separate accounts or invoices per index. A 5% platform fee applies to credit purchases. The platform marks up the cost you see per response to the provider rate listed on their pricing page, with no additional surcharge on the request itself.

Step 2: Get an API key

Create an OPENWEBSEARCH_API_KEY from the dashboard. The same key works for every provider — no need to rotate between Perplexity credentials, Exa tokens, or Brave keys separately.

Step 3: Send your first request

curl -X POST https://openwebsearch.ai/v1/search \
  -H "Authorization: Bearer $OPENWEBSEARCH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "providers": ["exa", "brave"],
    "query": "latest open source LLMs 2026",
    "numResults": 10
  }'

Every response returns a normalized shape with title, url, snippet, and content — the format most RAG pipelines and agent frameworks already expect. The provider-specific raw payload is also returned under raw if you need it.

Deeper Analysis

The normalization problem

Each search API returns results in a different structure. Exa uses its own schema, Brave uses another, Perplexity uses yet another. When you want to compare results across providers or swap one out for another, every integration point in your pipeline needs to change.

OpenWebSearch maps every provider’s output to the same four fields: title, url, snippet, content. Switching from Exa to Brave is a one-line change in the providers array — your downstream code does not change.

Fallback routing

Pass an ordered provider list and OpenWebSearch will automatically retry with the next provider if one returns an error or falls below its availability threshold. This is useful for production pipelines where a provider outage should not cause your agent to fail silently.

Per-request cost attribution

Every response includes a usage.cost field reporting exactly what that individual request cost. This makes it straightforward to attribute spend to specific queries or users without reconciling multiple provider invoices.

Zero data retention

OpenWebSearch does not retain your query text or results after the response is delivered. Only metadata needed for billing is kept: request ID, provider that served it, cost, and latency. Note that whichever provider receives the request applies its own data retention policy — if you need a specific retention guarantee, verify the provider’s policy and pin your provider list accordingly.

Practical Evaluation Checklist

• One API key for multiple search providers — verified on product page
• Normalized result shape across providers — verified from site FAQ
• Automatic fallback ordering — verified from site FAQ
• Per-request cost reporting — verified from site FAQ
• Plain REST API (returns JSON) — verified from site FAQ
• GET /v1/providers for live provider list — mentioned in site FAQ
• Credit-based pricing with 5% platform fee — verified from site FAQ
• No free tier visible on landing page — verified

Security Notes

• API key is passed as a Bearer token in the Authorization header
• Query content is not retained after response delivery
• Each provider applies its own data retention policy — check provider-specific terms when routing sensitive queries

FAQ

Q: Is there a free tier? A: No free tier is visible on the landing page. Pricing is credit-based, with per-1,000-request billing.

Q: Can I switch providers without changing my code? A: Yes. The request format and response shape are provider-agnostic. Only the providers array in the request changes.

Q: What happens if all providers in my list fail? A: The request returns an error from the last provider in the fallback chain. Your application handles this as a standard API error.

Q: Does OpenWebSearch add a markup on top of provider costs? A: No markup on the search itself. A 5% platform fee applies to credit purchases only.

Q: Is there an official library or SDK? A: No official library is listed. The product is a plain REST API compatible with any HTTP client or agent framework.

Conclusion

OpenWebSearch solves the multi-provider search integration problem by making the routing layer your concern instead of yours. One key, one request format, and normalized results let you swap search backends or add fallback redundancy without touching your pipeline downstream. The credit-based pricing with transparent per-request cost reporting makes it straightforward to track spend across providers. If you’re building RAG pipelines, agents, or data extraction workflows that query multiple search indexes, this removes a real operational tax.

Visit openwebsearch.ai to get an API key.