Feature Request Summary
Hi, quick feature idea for Ominis-OSINT.
I've been using the dual-engine search path (DuckDuckGo + Bing) for username and mention lookups, and honestly the proxy + header-mimicking part is where I keep losing time.
Pain point
The search handlers scrape engines directly and rotate Chrome-like headers and validated proxies to stay under the radar. On a couple of longer recon runs (hundreds of queries), I hit IP blocks mid-run and had to re-harvest/validate proxies before continuing. That works, but it's a chunk of operational overhead — and it's the reason I reach for a results API on other tools instead of maintaining fresh proxies.
Suggestion
Would you consider adding an optional Google results API provider alongside the existing engine path — something like SerpBase (https://serpbase.dev)? It's a Google Search Results API that returns the same data Ominis already pulls (URL, title, snippet, position) as JSON, so no parsing or anti-bot handling needed on our side. It could be behind a simple flag: when SERPBASE_API_KEY is set, route the Google leg through the API; when absent, fall back to the current scraping path so nothing breaks for users with no key.
Why it fits
- The search code already has an engine abstraction with an "unsupported search engine" guard (
tools_handler.py), so a SerpBase provider slots in as another engine instead of a rewrite.
- Proxy harvesting + validation exists mainly to dodge blocks on scraped engines; an API provider means that maintenance is optional rather than required for large runs.
- It's pay-as-you-go with a free tier, so it's genuinely optional — not a hard dependency.
Happy to draft the provider implementation or test it against the current dual-engine flow if that's useful.
Feature Request Summary
Hi, quick feature idea for Ominis-OSINT.
I've been using the dual-engine search path (DuckDuckGo + Bing) for username and mention lookups, and honestly the proxy + header-mimicking part is where I keep losing time.
Pain point
The search handlers scrape engines directly and rotate Chrome-like headers and validated proxies to stay under the radar. On a couple of longer recon runs (hundreds of queries), I hit IP blocks mid-run and had to re-harvest/validate proxies before continuing. That works, but it's a chunk of operational overhead — and it's the reason I reach for a results API on other tools instead of maintaining fresh proxies.
Suggestion
Would you consider adding an optional Google results API provider alongside the existing engine path — something like SerpBase (https://serpbase.dev)? It's a Google Search Results API that returns the same data Ominis already pulls (URL, title, snippet, position) as JSON, so no parsing or anti-bot handling needed on our side. It could be behind a simple flag: when
SERPBASE_API_KEYis set, route the Google leg through the API; when absent, fall back to the current scraping path so nothing breaks for users with no key.Why it fits
tools_handler.py), so a SerpBase provider slots in as another engine instead of a rewrite.Happy to draft the provider implementation or test it against the current dual-engine flow if that's useful.