
Newscatcher CatchAll API: Jag testade recall-first-sökning för AI-agenter
Jag ställde Newscatcher CatchAll API en envis fråga: hitta varje lagerbrand i Europa det här kvartalet. Inte de tio största. Alla. En vanlig sök-API ger dig en rankad sida med länkar och tappar tyst bort den långa svansen, vilket fungerar utmärkt för "bästa pizza häromkring" men är oanvändbart för ett enumeringsjobb. Ungefär 15 minuter senare, i Base-läge, kom CatchAll tillbaka med regionala tidningar och branschpublikationer som de rankningsbaserade API:erna i vårt best-ai-search-apis-2026-test aldrig hittade. Varje resultat kom som ett strukturerat JSON-objekt, inte en länk. Det gapet är hela historien.
Här är kortversionen innan vi går in på detaljerna.
Nyckelinsikter
- CatchAll är ett recall-first-webbsöke-API: det returnerar strukturerade händelseposter, inte en rankad SERP.
- Newscatcher rapporterar 79,8% recall och F1 0,705 över 32 frågor; startsidan avrundar detta till 86%.
- Två lägen: Lite (sekunder, ungefär 100-resultatgräns) och Base (asynkront, ca 15 minuter, ingen gräns).
- Passar bäst för enumeringsjobb (regelefterlevnad, konkurrensinformation, leveranskedjeövervakning); det är ingen SERP-rankingtracker.
Recall-first-sökning optimerar för att hitta allt, medan rankningsbaserad sökning optimerar för att ordna det fåtal den hittar. Håll den meningen i huvudet så faller resten av recensionen på plats.
Vad är CatchAll? (Recall-first-sökning förklarad)
CatchAll är ett recall-first-webbsöke-API från Newscatcher: i stället för en rankad lista med de tio bästa länkarna returnerar det en avduplicerad uppsättning strukturerade händelseposter, där var och en är ett enskilt JSON-objekt med källcitat och extraherade entiteter. Recall-first innebär att målet är fullständighet, att hitta varje relevant händelse, inte att ordna en kort lista efter relevans.
Newscatcher illustrerar det med en rättfram tankeövning: om 200 giltiga händelser finns och ditt system hittar 5 är din recall 2,5%. För "vilket är bästa laptopen" spelar det ingen roll. För "varje tillsynsåtgärd mot EU-fintechs i år" är ett 2,5%-svar värre än ingenting, eftersom du inte kan se vad du missar.
Det är det kategorigapet CatchAll riktar in sig på, och det är värt att förstå även om du aldrig registrerar dig. YC-lanseringspitchen kallar det ett "recall-first web search API", och du kan läsa positioneringen direkt på Newscatchers CatchAll Web Search API-produktsida. Den ärliga sammanfattningen: ett SERP-API svarar på "vad bör jag läsa först?" CatchAll svarar på "vad är den kompletta listan?"
Hur CatchAll fungerar: Retrieval + Validation-pipeline
CatchAll kör en femstegs-pipeline: frågeplanering skriver om din prompt till flera hämtningsvinklar, storskalig hämtning skannar 50 000+ sidor per jobb, Leiden-algoritmen klustrar relaterade sidor till enskilda händelser, en LLM validerar varje kluster mot din fråga, och de som klarar sig returneras som strukturerad JSON. Recall kommer från skanningen; precision kommer från valideringen.
Låt oss gå igenom dem snabbt:
- Frågeplanering. Din enda fråga förvandlas till flera hämtningspromptar som täcker olika formuleringar och händelsetyper, så att "lagerbrand" också fångar "eldsvåda vid logistikdepå."
- Storskalig hämtning. Newscatcher uppger att ett enda jobb hämtar 50 000+ sidor med ungefär 10 000 sidor per minut utan resultatgräns, och når regionala tidningar, branschpublikationer och tillsynsmyndighetsregister som vanliga SERP:er begräver.
- Klustring. Leiden-algoritmen grupperar tätt sammankopplade sidor till kluster. På klarspråk: 30 artiklar om samma brand i Rotterdam kollapsar till en händelse, inte 30 rader.
- LLM-validering. Varje kluster poängsätts mot din fråga, och irrelevanta faller bort. Det här steget kostar riktiga LLM-anrop, så i en produktions-agent-stack vill du routa dem via en LLM gateway för kostnadskontroll och fallback.
- Strukturerad output. Ett JSON-objekt per validerad händelse, med ett dynamiskt schema.
Newscatcher uppger att de indexerar mer än 2 miljoner verkliga händelser dagligen, där nya händelser dyker upp inom timmar. Det tekniska dokumentet "The Architecture of Completeness" täcker Leiden-algoritmen och valideringsdetaljerna om du vill ha djupet.
Det var här mitt lagerbrands-test levde. Jag körde enumeringsfrågan i Base-läge, jobbet tog ungefär 15 minuter, och värdet dök upp exakt där pipeline-löftet säger det: regionala och branschifrågade källor, klustrade till diskreta händelser, som en rankad SERP hade begravt nedanför vad ögat ser.
Nyckelfunktioner: Monitors, Watchlists och händelseextraktion
Utöver engångssökningar levererar CatchAll Monitors och Watchlists. Monitors är schemalagda omkörningar (minst varje timme) som bara returnerar nya, avduplicerade händelser sedan senaste körningen. Watchlists filtrerar efter entitet med ett relevanspoäng på 1–10 och entitetsupplösning som matchar samma företag över språk och jurisdiktioner.
Monitors förvandlar en engångssökning till en stående bevakning: varje körning returnerar bara de händelser som är nya sedan senast. Det är skillnaden mellan "sök webben idag" och "berätta så fort något förändras."
En ärlig reservation om "realtidshändelseövervakning"-framing: "realtid" här innebär timvisa omkörningar, inte sub-sekund streaming. Om du behöver push-notiser på millisekunder är det inte det här. För ett complianceteam som kollar två gånger om dagen räcker timvisa körningar mer än väl. Company Watchlist är höjdpunkten för konkurrensinformation, eftersom den löser upp "Acme GmbH", "Acme Inc" och "Acme Holdings" till en enda spårad entitet i stället för tre brusiga.
Strukturerad JSON-output (med ett riktigt exempel)
Varje resultat är en händelse som ett JSON-objekt: ett cluster_id, en title, ett relevance-poäng, en entities-array och en source_citations-array. Ingen HTML-skrapning, ingen länklista att tolka. Det är det som gör CatchAll till ett genuint strukturerat webbsöke-API snarare än en SERP-wrapper.
Här är en trunkerad händelse från mitt lagerbrands-test, lätt städad men äkta till formen:
{
"events": [
{
"cluster_id": "evt_8f21a",
"title": "Fire at logistics warehouse near Rotterdam",
"relevance": 9,
"entities": [
{"name": "Rotterdam", "type": "location"},
{"name": "Maasvlakte", "type": "facility"}
],
"source_citations": [
{
"url": "https://...",
"publisher": "regional trade press",
"published_at": "2026-..."
}
]
}
]
}Lägg märke till att source_citations-arrayen pekar på en regional branschsajt, exakt den typ av källa som ett ranknings-API nedprioriterar. Eftersom varje händelse redan är strukturerad kan du droppa de validerade posterna direkt i en RAG-pipeline eller lagra och embedda dem i en vektordatabas utan ett skrap- eller städsteg emellan. Det sparade steget är den tysta produktivitetsvinsten.
Hur anropar du CatchAll i Python? (Kodsnabbstart)
Du skaffar en API-nyckel, POSTar din fråga till /v3/search med x-api-token-headern och tolkar events-arrayen. Det är hela loopen. Här är ett minimalt Python-anrop:
import requests
resp = requests.post(
"https://api.newscatcherapi.com/v3/search",
headers={"x-api-token": "YOUR_API_KEY"},
json={"query": "warehouse fires in Europe", "page_size": 10},
)
events = resp.json()["events"]
for ev in events:
print(ev["title"], "—", ev["relevance"])Protips och fallgrop i ett: Lite-läge returnerar på sekunder men begränsar sig till ungefär 100 resultat, medan Base-läge är asynkront och tar ungefär 15 minuter för ett djupt jobb. För Base skickar du och pollar i stället för att blocka på ett enskilt anrop, så bygg din agent att avfyra-och-kontrollera, inte vänta. Om du kopplar in CatchAll i en agent anropar du det typiskt som ett verktyg via function calling. Bekräfta de exakta request-parametrarna och Lite-kontra-Base-flaggan mot CatchAll-dokumentationen innan du levererar; auth-headern är x-api-token.
Vad kostar CatchAll? Finns det en gratisplan?
Prissättningen är användningsbaserad och pay-per-validated-record, ungefär 0,10 dollar per post, och noll resultat innebär noll kostnad. Det finns en gratisplan med ungefär 2 000 krediter vid registrering plus ungefär 10 sökningar per månad, utan kreditkortkrav, så du kan köra ett riktigt enumeringstest innan du satsar pengar.
Den nollkostnad-vid-nollresultat-modellen spelar roll för enumeringsjobb: en fråga som legitimt saknar matchande händelser bränner inte budget. På den vanliga frågan om Googles sök-API är gratis: Googles och Bings native-sökning är inte det här. De returnerar rankade länkar, inte validerade strukturerade händelser, och Bings Search API håller på att avvecklas, vilket delvis förklarar varför oberoende index har sitt ögonblick just nu.
Verkliga användningsfall
CatchAll passar vilket jobb som helst där att missa en enda händelse är felläget. Regelefterlevnad och tillsynsspårning lutar sig mot Monitors och dess regulatoriska täckning. Konkurrensinformation kör på Company Watchlist. Leveranskedjeövervakning är lagerbrands-mönstret, att bevaka störningshändelser. Marknadsundersökning använder enumerering av branschpress.
Mönstret är gemensamt för alla fyra: du bygger en komplett lista och agerar sedan på den, ofta inuti ett automatiserat webbsöke-API för AI-agenter-workflow. Några konkreta former:
- Regelefterlevnad: stående Monitor på tillsynsåtgärder i din sektor, varje timme.
- Konkurrensinformation: Watchlist på tre rivalentiteter, upplösta över deras juridiska namn.
- Leveranskedja: enumerering av störningshändelser (bränder, strejker, återkallelser) nära dina leverantörsanläggningar.
- Marknadsundersökning: engångs Base-skan av varje produktlansering i en nisch det här kvartalet.
Benchmarkresultaten: Är CatchAll verkligen 3x bättre än Exa?
I Newscatchers eget benchmark från mars 2026 med 32 frågor rapporterar CatchAll F1 0,705 och 79,8% recall (4 807 händelser), och vann 27 av 32 frågor mot Exa Websets, Parallel AI FindAll och OpenAI Deep Research. Newscatcher beskriver det som ungefär 3 gånger fler relevanta händelser än konkurrenterna. Varje siffra här är leverantörens egna uppgifter.
| Verktyg (Newscatchers test mars 2026, 32 frågor) | F1 | Recall |
|---|---|---|
| CatchAll | 0,705 | 79,8% (4 807 händelser) |
| Exa Websets | 0,317 | 19,6% |
| Parallel AI FindAll | 0,103 | 5,5% |
| OpenAI o3 / Deep Research | 0,017 | 0,9% |
Nu till den ärliga delen. Newscatchers eget rigorösa benchmark säger 79,8% recall; startsidan avrundar det till 86%. Vi citerar det lägre talet. Siffran 79,8% kommer från den daterade, detaljerade 32-frågors produktsidetabellen, medan 86%-rubriken är ett rundare påstående från ett annat snitt på startsidan och ett blogginlägg. Båda är Newscatchers egna. Jag leder med det lägre för att citera en leverantörs mer konservativa interna siffra är det förtroendebyggande draget en marknadsföringssida inte kan göra. Hur som helst stämde den riktningsgivande slutsatsen i mitt test: recall är genuint högre än med rankningsbaserade verktyg. För hela fältet, se hur CatchAll rankar mot 12 andra AI-sök-API:er i vår sammanfattning av de bästa AI-sök-API:erna, och kolla den råa tabellen direkt på Newscatchers produktsida.
Ärliga begränsningar: Vad CatchAll INTE är till för
CatchAll har fyra verkliga begränsningar som marknadsföringssidorna gömmer undan, och du bör väga dem innan du bygger. Det är inte låg-latens, inte obegränsat i snabbläget, inte plug-and-play för agenter ännu, och ingen rankingtracker. Ingen av dem är en dealbreaker, men varje utesluter ett användningsfall.
- Base-läge är asynkront (ca 15 minuter per jobb). Fel verktyg för en chatbot som behöver svar på två sekunder.
- Lite-läge begränsar sig till ungefär 100 resultat. Vill du ha djup recall snabbt? Det går inte att få båda; djup recall betalar latens-skatten.
- Ingen officiell MCP-server ännu. Du wrapprar REST-endpointen själv. Om du vill ha det som ett native agentverktyg, wrappa REST-endpointen som en MCP-server, på samma sätt som vi bygger de MCP-servrar vi redan använder.
- Det är ingen SERP eller rankingtracker. Det berättar inte var du rankar på Google. Helt annat jobb.
Det här avsnittet är det ingen förstapartssida skriver åt dig. Om asynkronlatensen eller den saknade MCP-servern förstör ditt användningsfall är det bättre att lära sig det här än efter integration.
CatchAll-alternativ och när du ska välja dem
CatchAll vinner på rå recall för enumerering, men det är inte rätt val för varje sökjobb. Här är sju verkliga alternativ, vart och ett med det ärliga "välj det här i stället"-villkoret. Inga halmgubbar.
| Verktyg | En rads positionering | Välj det här i stället om… |
|---|---|---|
| Exa / Exa Websets | Neural/semantisk sökning plus enumererade Websets | Du vill ha semantisk discovery och embeddings-relevant relevans framför rå recall, med mindre och snabbare resultatsatser. |
| Parallel AI (FindAll) | Agentisk enumererings/research-API | Du redan är i Parallel-ekosystemet och vill ha deras uppgiftsstyle-research-primitiv. |
| OpenAI Deep Research | LLM-driven flerstegs webbresearch | Du vill ha en nyckelklar research-agent inuti OpenAI-stacken och tål sampling framför uttömmande recall. |
| Tavily | Citation-formad sökning byggd för RAG/LangChain | Du vill ha den enklaste realtids-RAG-sökningen med extraction i ett anrop och native framework-integrationer. |
| Brave Search API | Oberoende index, integritet, snabb SERP-stil | Du behöver leverantörsoberoende plus låg latens och en rankad resultatsida passar bra. |
| SerpAPI / Serper | Google/flermotor-SERP-skrapning | Du behöver SEO-rankingspårning, SERP-funktioner eller att spegla exakt vad Google visar. |
| Linkup | EU/utgivarkälle-fokuserad sökning | Ditt användningsfall är europeisk utgivartäckning och licenserade källors ursprung. |
Snabbheuristiken: enumerering och övervakning pekar mot CatchAll, konversations-RAG pekar mot Tavily, semantisk discovery pekar mot Exa, och rankingspårning pekar mot SerpAPI.
Hur Techsy använder recall-first-sökning i agentbyggen
På Techsy levererar vi AI-agenter till B2B-kunder, och recall-first-sökning passar in rent för enumererings- och övervakningsjobb: tänk en complianceagent som behöver den kompletta listan över tillsynsåtgärder, inte de fem bästa. Vi väljer ett recall-first-API som CatchAll där, och väljer ärligt nog Tavily eller Exa när uppgiften är konversations-RAG eller semantisk lookup i stället. Att välja fel sökprimitiv är ett av de vanligaste agentbyggmisstagen vi åtgärdar. Vill du ha hjälp med att välja? Boka en kostnadsfri konsultation.
Om skribenten
Mert Batur är medgrundare av Techsy.io, där teamet levererar AI-agenter, automationssystem och voice/SDR-pipelines för B2B-kunder. Han skriver om det LLM-verktygsstack som Techsy-teamet faktiskt använder i produktion. Anslut på LinkedIn.
Vanliga frågor
Vad är Newscatcher CatchAll API?
CatchAll är ett recall-first-webbsöke-API från Newscatcher. I stället för en rankad länklista returnerar det strukturerade händelseposter, ett JSON-objekt per verklig händelse, var och en med källcitat och extraherade entiteter. Det är byggt för AI-agenter, företagsforskning och övervakningsuppgifter där att hitta varje relevant händelse spelar större roll än att ordna en kort lista.
Hur skiljer sig CatchAll från ett vanligt (SERP) sök-API?
Ett SERP-API rankar och returnerar ett fåtal av de bästa länkarna, och optimerar för "vad bör jag läsa först." CatchAll optimerar för fullständighet och skannar 50 000+ sidor per jobb och klustrar dem till avduplicerade strukturerade händelser. Du får ett objekt per händelse med citat och entiteter, inte en HTML-resultatsida som du måste skrapa och tolka själv.
Är CatchAll verkligen 3x bättre än Exa Websets?
Newscatcher rapporterar det i sitt eget test från mars 2026 med 32 frågor: CatchAll på 79,8% recall och F1 0,705 mot Exa Websets på 19,6%, och vann 27 av 32 frågor, vilket de ramar in som ungefär 3 gånger fler relevanta händelser. Notera att startsidan avrundar recall till 86% från ett annat snitt. Alla siffror är leverantörens egna; behandla dem som tillskrivna, inte oberoende granskade.
Vad kostar CatchAll? Finns det en gratisplan?
Prissättningen är användningsbaserad och pay-per-validated-record, ungefär 0,10 dollar per post, utan kostnad när en fråga inte ger resultat. Gratisplanen ger ungefär 2 000 krediter vid registrering plus ungefär 10 sökningar i månaden, utan kreditkortkrav. Det räcker för att köra ett riktigt enumeringstest mot ditt eget användningsfall innan du satsar budget.
Hur snabb är CatchAll?
Det beror på läget. Lite returnerar på sekunder men begränsar sig till ungefär 100 resultat. Base är asynkront och tar ungefär 15 minuter per jobb, utan resultatgräns, för djup enumerering. För Base-jobb skickar du och pollar snarare än att blockera på ett anrop, så det passar inte för något som behöver sub-sekund-svar som en livechatbot.
Har CatchAll en MCP-server?
Ingen officiell ännu. För att använda det som ett native agentverktyg idag wrapprar du REST-endpointen själv, samma mönster som täcks i vår MCP-guide. Det är en tunn wrapper runt ett enda POST till /v3/search, så att bygga en liten MCP-server runt det är okomplicerat om din stack redan pratar protokollet.
Vad är Monitors och Watchlists?
Monitors är schemalagda omkörningar, minst varje timme, som bara returnerar nya avduplicerade händelser sedan senaste körningen, och förvandlar en engångssökning till en stående bevakning. Watchlists filtrerar resultat efter entitet med ett relevanspoäng på 1–10 och löser upp samma företag över språk och jurisdiktioner. Tillsammans täcker de regelefterlevnadsspårning och konkurrensinformation utan att behöva fråga om hela webben varje gång.
Kan jag använda CatchAll för SEO-rankingspårning?
Nej. CatchAll returnerar validerade strukturerade händelser, inte sökmotorankningar, så det berättar inte var din sida hamnar på Google. För rankingspårning, SERP-funktioner eller att spegla exakt vad Google visar, använd SerpAPI eller Serper i stället. CatchAll och rankingtracker löser genuint olika problem trots att båda rör "webbsökning."
Vad är CatchAll bäst för?
Enumererings- och övervakningsuppgifter där fullständighet spelar roll: regelefterlevnad och tillsynsspårning, konkurrensinformation, leveranskedjeövervakning och marknadsundersökning i branschpress. Den gemensamma tråden är att missa en enda relevant händelse är felläget, vilket är exakt vad recall-first-sökning är designat att förebygga. För konversations-RAG eller semantisk lookup passar ett rankningsbaserat verktyg bättre.
Slutsatsen: recall-first är inte rankad, och det är poängen. CatchAll byter latens mot fullständighet, och för enumeringsjobb är det rätt byte. Kör gratisplanen på din svåraste fråga innan du bestämmer dig, eftersom du kan testa CatchAll:s gratisplan utan kreditkort. Om asynkronväntan eller den saknade MCP-servern är ett dealbreaker passar ett alternativ från tabellen ovan dig bättre.