DEV Community: Oleksyj Mokrousov

Best News Sources: AI Top Lists vs Perigon's top100 Source Group

Oleksyj Mokrousov — Tue, 28 Jul 2026 10:07:02 +0000

Why “best news sources” lists disagree

Ask three assistants for the top news sources - with domains - and you get three confident shortlists that optimize for different jobs. One model ranks wire and reputation brands.

Another ranks monthly traffic. A third mixes both and folds in aggregators. That is useful brainstorming. It is a weak foundation for a production news source allowlist, where the publisher set must stay stable across Articles and Stories jobs.

We compared ChatGPT, Claude, and Gemini top-8 answers, then lined them up against Perigon’s public top100 source group (ID 15, display name Most popular - about 94 domains). Across the three AI lists, only three publishers appear on every roster: BBC, The New York Times, and CNN. Everything else is a bias toward wires, portals, or partisan traffic leaders.

This article covers:

Why AI-generated best news sources lists disagree

What top100 covers that short lists drop

How to monitor general news with that source group

How to filter news by source, topic, company, and date inside the pack

Try it live: Sources sandbox · Docs: Sources and source groups · Plans: API pricing

Vertical packs (different SERPs): top25finance · healthcare trade pubs. This page owns the general most popular pack only.

Why AI top-8 news lists are not a production allowlist

The disagreement is not noise - each model answers a different reading of “top”:

ChatGPT leans influence and international desks: Reuters, Associated Press, BBC, NYT, Washington Post, WSJ, Bloomberg, CNN. Strong for wires and prestige brands; light on pure traffic portals.

Claude leans Similarweb-style traffic: Yahoo (including Japan), BBC, NYT, CNN, Fox News, USA Today, Daily Mail. Strong for visit volume; includes aggregator/portal surfaces that are not traditional newsrooms.

Gemini mixes both and adds The Guardian, Reuters, Yahoo, and MSN - calling out that portals often rank high because they are homepages, while original reporting still comes from wires and newspapers.

What AI does	What breaks in production
Returns a neat “top 8”	Misses local metros, lifestyle desks, and half the opinion spectrum your product may need
Sounds authoritative	Different model → different publishers → different alert quality
Optimizes for one ranking lens	Traffic ≠ reputation ≠ “trusted” - and none of those lenses equals a maintained group name

Treat LLM shortlists as research signals. Do not paste them into source= forever and call the feed done.

The fuller picture: top100 (most popular)

Field	Value
Name	top100
Display name	Most popular
Source group ID	15
Size	~94 domains
Scope	Top most popular sources globally

Pass sourceGroup=top100 on Articles (/v1/all), Headlines, or Stories. Inspect members via the Sources API with the same group name - without dumping every domain into this article twice.

Rather than stopping at eight household names, the group spans the lanes that show up when teams actually ship a popular news feed:

1) Wires and global brands - Reuters, AP, BBC, NYT, Washington Post, WSJ, Bloomberg, CNN, and peers the reputation-style lists already name.

2) High-traffic digital and cable - Fox News, USA Today, Daily Mail, HuffPost, NBC, CBS, ABC, and similar mass-reach desks.

3) U.S. metro and regional papers - Los Angeles Times, Boston Globe, Chicago Tribune, Seattle Times, Miami Herald, and other city desks short “global top 8” lists almost never assemble.

4) Business and markets adjacent - CNBC, Forbes, Yahoo Finance, Quartz - without requiring the finance-only top25finance pack.

5) Opinion and partisan digital - outlets across the spectrum (from Breitbart and Daily Wire to Daily Kos and Raw Story) so a “popular” feed is not accidentally center-only.

6) Lifestyle and culture - People, BuzzFeed, Cosmopolitan, Variety, Vanity Fair - the consumer layer pure politics lists drop.

7) International English desks - Al Jazeera, South China Morning Post, The Guardian, Telegraph, and others beyond a U.S.-cable shortlist.

How the group compares with the AI picks

Almost every domain the three models named is already inside top100. The practical gaps run the other way: short lists never assemble metro papers, lifestyle titles, or the broader opinion set that a “most popular globally” pack includes.

Honest misses relative to the AI traffic answers:

yahoo.co.jp (Claude’s global traffic leader) is not in this snapshot - the pack includes yahoo.com / finance.yahoo.com instead.

msn.com (Gemini) is not listed as such; the group includes Microsoft’s ms.now surface. If you need a specific portal hostname, add it with source= or a private group.

That is the point of a curated sourceGroup: one reusable name for the popular-publisher fence, not a chat paste that changes when you switch models.

How to monitor news with top100

Scope popular publishers first, then keywords or entities. Without a publisher gate, open-web search for politics, markets, or breaking topics pulls blogs, SEO farms, and press-release mills alongside serious desks. Lock the outer fence with sourceGroup=top100, then narrow.

Pattern on Articles: pass sourceGroup set to top100, add q for the beat you care about, and poll with from / to or addDateFrom for digests. For a company or person watch inside popular outlets, stack companySymbol / companyId or personWikidataId the same way - the Company and People guides own the full entity cookbook; here the group is the allowlist.

Use the same sourceGroup on the Stories API when one event reprints across many major outlets - you track the narrative cluster once instead of every mirror URL. For a short briefing of that filtered set, pass results into Search Summarizer. Vertical desks that need trade pubs only should use the industry packs (finance, healthcare, automotive, industrial) rather than stretching top100 into a niche B2B feed.

Filter popular news by source, topic, company, and date

Goal	Mechanism	Notes for general feeds
Popular-publisher allowlist	sourceGroup=top100	Most-popular global pack (15)
One-off domain	source / excludeSource	Portals or titles missing from the snapshot
Who is mentioned	companyId / companySymbol / people filters	Inside the group
What it is about	topic, category, taxonomy	e.g. Politics slice inside top100
When	from / to / addDateFrom	Digests and incremental monitors

Creating private forks of the pack (your own curated list on top of or instead of top100) lives in the Source Groups guide - this page only applies the public name.

When an AI list is a brainstorm vs when you need top100

Situation	Prefer
Ideation slide (“brands we recognize”)	AI shortlist - then verify
Production best news sources feeds and alerts	top100 (15)
Finance-only or healthcare-only desk	Vertical pack (top25finance, healthcare trade pubs, …)
Must-have portal hostname absent from the ~94	Private group or source=
Publisher metadata (geography, paywall, traffic)	Sources API + group name

Scale inside the pack (last 30 days)

Live Articles counts for 2026-06-19 through 2026-07-19 (pubDate window):

About 604,000 articles matched sourceGroup=top100.

About 28 million articles matched an open q=* baseline in the same window - so the popular pack is a small, high-signal slice of total index volume (on the order of 2%).

About 110,000 of the top100 hits also carried category Politics.

About 38,500 Stories clusters matched sourceGroup=top100 in the same window - useful when you care about narrative heat, not every URL.

Round large numResults in product copy; very large baselines can sit near plan or index caps, so prefer the relative comparison (popular pack vs open web) over treating any single integer as exact forever.

Key takeaways

AI best news sources top-8 lists disagree because they optimize for reputation, traffic, or a mix - only BBC, NYT, and CNN were unanimous across the three we compared.

top100 (15) is the maintained most popular allowlist (~94 domains): wires, national desks, metros, opinion, lifestyle, and international English - not eight chat suggestions.

Filter news by source with sourceGroup=top100, then stack q, entities, category, and dates for desk-specific feeds.

Use LLM lists to brainstorm; use the curated group for production. For industry-only SERPs, switch to the matching vertical pack instead of overloading top100.

Get started: Sources sandbox · Sources and source groups · API reference · API pricing

Left vs Right Political Journalists Compared

Oleksyj Mokrousov — Tue, 28 Jul 2026 10:05:39 +0000

Building political media monitoring without ideology fields

Teams searching for left vs right political journalists usually need a political monitoring system: two reusable byline datasets, transparent rules, and stable IDs they can apply on article search. They do not need an editorial ranking of reporters.

Perigon does not assign left/right ideology to journalists. There is no journalist-level lean parameter. Any “left vs right” framing in your product comes from publisher clusters you define, then from journalists whose profiles match those publishers. This guide teaches that reproducible methodology - data quality, verification, and journalist identity resolution - so the dataset stays accurate when people change employers.

Why are keyword searches unreliable for partisan media reporters?

How do customer-defined publisher clusters create comparable datasets?

What is the end-to-end workflow from cluster → resolved IDs → Articles?

How do you keep datasets trustworthy as affiliations change?

When should you use Journalists vs Sources vs People?

The sections below answer each in order. Full Journalists parameter reference lives in the Journalists API guide and the Entities docs linked above; this page owns the monitoring methodology.

Try it: Journalists sandbox · Docs: Entities · Pricing: API pricing

Why keyword ideology search fails

Searching q for “liberal,” “conservative,” “left,” or “right” does not produce a defensible partisan journalist list. Those tokens appear in quotes, horse-race copy, sports “left tackle,” and photo captions. Different people share the same byline string. Keyword hits are not reproducible ideology membership.

Publisher clustering outperforms keyword-based ideology search because membership is explicit: you decide which domains belong in Pack A and Pack B, document that choice, and resolve journalists against source (optionally with category=Politics, country=us, or label = Opinion). Two engineers re-running the same pack definitions get the same discovery inputs. That is the foundation of media lean journalist discovery as engineering practice - not as a claim about individuals’ beliefs.

Publisher clusters are defined by the customer

In this workflow, “left” and “right” are labels on your publisher packs, not attributes returned by the Journalists API.

Concept	Owner
Which domains sit in Pack A / Pack B	Your product, research, or compliance rules
Whether Opinion-heavy sites belong in a pack	Your product
Journalist profile fields (title, topSources, id)	Perigon index
Ideology of a person	Not provided by the API

Different organizations choose different outlet lists for good reasons: brand risk, geographic focus, inclusion of opinion vs newsroom domains, licensed publishers, or internal media-bias taxonomies. Two customers can both build left vs right journalists monitors and disagree on whether a given domain belongs in a pack. That disagreement is expected. Document the pack version (domains + date + rationale) next to any saved ID list so audits can reproduce results.

Example pack shapes (illustrative only - replace with your approved domains):

Your label	Role in the system	Example domain pattern
Pack R	Customer-defined “right” publisher set	Domains your policy treats as that cluster
Pack L	Customer-defined “left” publisher set	Domains your policy treats as that cluster

Do not treat any sample domain list in a blog post as Perigon’s official ideology map. The API only answers: which journalists are associated with the publishers you queried.

Reproducible workflow: cluster → resolve → verify → save → apply

Use the same pipeline for both packs. Keep pack membership metadata on every saved row.

Define publisher clusters
Store Pack L and Pack R as versioned domain lists (and optional rules such as “Opinion allowed”).

Resolve journalists
On /v1/journalists/all, query with source set to the pack’s domains. Narrow with category, country, label, or minMonthlyPosts as your quality bar requires. For known bylines, use name / twitter and then verify.

Verify before save
For each candidate, confirm title and topSources still match the pack you intend. Reject near-matches, empty activity, or profiles whose top publishers fall outside the pack.

Save reusable journalist IDs
Persist journalistId, pack label, pack version, verification timestamp, and optionally the topSources snapshot you accepted.

Use journalistId on Articles
On /v1/all, pass journalistId (OR) or excludeJournalistId (AND) to build feeds. The ID identifies the byline match - it does not encode ideology. Ideology, if any, remains the pack label you attached in step 4.

That pipeline is the primary topic of this page: building publisher-based journalist datasets for political media intelligence, while still matching search intent around left vs right political journalists.

Journalist identity resolution and byline disambiguation

Journalist identity resolution means mapping a human byline to a single stable id in the journalist index. Common failure modes:

Failure	Mitigation
Shared or similar names	Compare title, Twitter handle, and topSources; do not pick the first row
Syndication noise	High post volume across many domains can pull in off-pack publishers - require pack overlap in topSources
Empty or stale profiles	Prefer profiles with recent updatedAt / non-zero avgMonthlyPosts when activity matters
Domain filter returns zero	Some brands publish under alternate hosts; fall back to name resolve, then verify sources

Byline disambiguation is a data-quality gate, not a political judgment. If title and topSources do not support membership in the customer pack, do not save the ID into that pack’s dataset.

Data quality: verify title and topSources every time

Before a profile enters production:

1) Read title - does the role match the desk you monitor (politics, opinion, correspondence), or is it sports/lifestyle collision?

2) Read topSources - do the leading domains intersect your pack version?

3) Optionally check topLabels / topTopics as secondary signals, not as ideology classifiers.

4) Record who verified the row and when.

Skipping verification is how partisan media reporters datasets silently fill with wrong people. Reproducibility requires the verification step to be part of the written method, not an optional polish.

Affiliations change: refresh saved journalist IDs

Journalists change employers, shows, and syndication patterns. A journalistId remains a useful primary key, but pack membership is time-bound:

Schedule a periodic refresh (for example monthly or each pack-version bump).

Re-fetch /v1/journalists/{id} or re-run name resolve.

Re-check title and topSources against the current pack.

Move IDs between Pack L and Pack R only when your policy says the publisher footprint changed - and log the change.

Retire IDs that no longer meet the quality bar.

Evergreen monitors depend on this maintenance loop. Static “lists of left vs right journalists” scraped once will drift.

Integrate Journalists API results with the Articles API

After IDs are verified and labeled with a pack version:

Articles parameter	Use in political monitoring
journalistId	Include bylines from one pack (or a union you explicitly label)
excludeJournalistId	Drop bylines that flood or fail QA
author / excludeAuthor	Name-only fallback when an ID is not yet resolved - weaker than IDs

Combine with your usual article filters (q, dates, category) for event language. Keep pack ideology metadata in your datastore; do not expect Articles responses to return left/right on the journalist object.

When to use Journalists vs Sources vs People

Monitoring question	API family
Which writers match our publisher packs?	Journalists → save journalistId
Which publishers define the packs / outlet skew?	Sources / source groups
Which people are mentioned as subjects (candidates, officials)?	People (personName, personWikidataId)

Mixing these layers is a common design bug: treating a mentioned politician as a byline, or treating a source-group lean pack as a journalist ideology field. Keep writer, publisher, and subject as separate allowlists.

Resolve smoke tests (not rankings)

The following IDs are resolution examples from live lookups - used to illustrate verification, not to rank or endorse anyone. Each row is “this profile resolved; confirm topSources against your pack before production use.” Ideology is only whatever pack label you attach after verification.

After querying a customer Pack R (illustrative domains such as foxnews.com / nationalreview.com / thefederalist.com / washingtonexaminer.com):

Name	Resolved id	Verification cue
Bret Baier	377c544662ed4358921cba67a336ef4f	Title + foxnews.com in topSources
Byron York	677cd5fe712f44b680f7ec815edbd365	washingtonexaminer.com in topSources
Rich Lowry	67a37bc03b434bd0a481d52fdda47b56	nationalreview.com in topSources

After querying a customer Pack L (illustrative domains such as nytimes.com / washingtonpost.com / huffpost.com):

Name	Resolved id	Verification cue
Jamelle Bouie	891fe2e6b12a4518b61d045f4172fad5	Columnist title + nytimes.com in topSources
Jennifer Rubin	dff54a11b7954148b08a39e07403b035	Opinion-writer title; re-check live topSources before save
Rachel Maddow	e93c35d952cc4dd88d68c38b748f3ca4	Host title; confirm current topSources (domain filters for some TV brands can return empty - name resolve + verify)

If verification fails, do not keep the ID in that pack’s dataset. Replace with another resolved profile that passes your gates.

Key takeaways

Search intent for left vs right political journalists is best served by publisher-cluster datasets, not keyword ideology queries.

Perigon does not label journalists as left or right; pack definitions and ideology labels are yours.

Workflow: define clusters → resolve → verify title / topSources → save versioned IDs → apply journalistId on Articles.

Refresh saved IDs as affiliations and topSources change.

Use Journalists for writers, Sources for publishers, People for mentioned subjects.

Get started: Journalists sandbox · Entities · API pricing

Perigon SDK Overview: Official Client Libraries for the News API

Oleksyj Mokrousov — Tue, 28 Jul 2026 10:04:08 +0000

The real question is not “is there an SDK?”

Most teams already know Perigon publishes an official news SDK. The harder API onboarding question is whether your product should call the News API through that software development kit or through raw HTTP / REST forever.

This page is only a SDK vs HTTP / REST vs SDK decision guide. Exact packages, install steps, and typed-client ergonomics live on Perigon SDKs plus the sibling install and typed-client posts. Articles search design stays on the practical news API guide.

What problem does a Perigon SDK actually solve on the API integration path?

When does a multi-language SDK change the build-vs-buy transport decision?

When should you choose news SDK clients instead of raw REST?

Which architecture tradeoffs still favor owning HTTP yourself?

The sections below answer each in order.

Read the docs: Perigon SDKs · Developer home: Getting started · Compare plans: API pricing

What is the Perigon SDK for, architecturally?

The Perigon SDK is Perigon's official news SDK: maintained news API client libraries that sit between your application and the REST News API. From an architecture view, the SDK is a transport abstraction - your code talks to a client object; the client owns serialization, auth attachment, and response decoding.

That matters for developer productivity and long-term maintenance more than for “having a package.” Without an official client, every service invents its own thin wrapper. Six months later you have three incompatible helpers, none of which track docs changes. With the SDK, onboarding a new engineer means “use the supported client,” not “copy the curl from Slack.”

The SDK is not a different API and not a substitute for learning which filters to pass. It changes who maintains the HTTP edge - Perigon’s official client libraries versus your team.

Multi-language SDK coverage as a staffing decision

A multi-language SDK is less about collecting languages and more about matching the runtimes you already staff. If your backend is already standardized on a supported stack, picking the news API SDK for that stack is usually the default API integration path. If your edge workers, ETL jobs, and mobile backends each speak a different language - and only one of them has an official client - you need an explicit policy: SDK where supported, thin REST where not, rather than forcing one language’s package into every process.

Unsupported runtimes are not a failure of the SDK; they are a signal to stay on HTTP (or request another binding via the SDKs docs) instead of pretending a missing client exists.

REST vs SDK: decision scenarios

Situation	Prefer	Why
Spike in Postman / curl to learn filters	Raw HTTP	Fastest feedback loop; no package lifecycle
Production service on a supported runtime	Perigon SDK	Lower maintenance; shared patterns across teams
Many services, one platform team	SDK (client library vs REST)	One supported onboarding path
Exotic runtime or strict “no third-party clients” policy	HTTP you own	You accept wrapper maintenance
Query design still fluid	Learn filters first, then lock transport	Do not block product learning on packaging

SDK vs raw REST is rarely about feature parity - both hit the same endpoints. The tradeoff is maintenance, onboarding, and long-term support: who upgrades when parameters or models change, and how many home-grown clients you are willing to babysit.

Prefer the SDK when transport should be boring and identical across services. Prefer HTTP when you need maximum control, minimal dependencies, or a runtime outside the official set.

Architecture tradeoffs that still favor owning HTTP

Some teams should keep raw REST even when an SDK exists:

1) Compliance / supply-chain rules that freeze third-party client libraries

2) Ultra-thin edge workers where every dependency byte is budgeted

3) Polyglot glue that already centralizes HTTP in an internal gateway - the gateway speaks REST; apps never see Perigon directly

4) Experimental research notebooks that change weekly and should not pin SDK majors

Those are conscious HTTP client vs SDK choices. If none of them apply, choosing the official client libraries is usually the lower-risk default.

How to sequence the decision (without installing anything here)

Decision	Where to go next
SDK vs HTTP for this service	This overview
How to install and authenticate safely	SDK install best-practices guide
Why typed clients help large codebases	Typed SDK clients / DX guide
Which filters and feeds to build	Practical news API guide

Key takeaways

Treat the Perigon SDK as transport ownership and developer productivity, not as a second News API.

Multi-language SDK coverage answers “can my staffed runtime use an official client?” - not “which command do I run?”

Prefer the SDK for production on supported stacks; prefer raw REST for spikes, exotic runtimes, or deliberate HTTP ownership.

This page only answers when to use SDK vs HTTP; packages, keys, and typed DX live elsewhere.

Get started: Perigon SDKs · API pricing

Monitor Middle East Conflict News

Oleksyj Mokrousov — Tue, 28 Jul 2026 10:02:34 +0000

Why teams monitor Middle East conflict news

The Middle East is rarely a single story. On any given week, coverage spans Israel-Gaza, Iran and its nuclear file, Lebanon and Hezbollah, Red Sea shipping attacks, and the diplomacy around all of them - each moving at a different speed. Analysts, risk teams, and newsrooms that watch the region need to catch escalations early without drowning in duplicate wire copy, and they need to tell a genuine turning point apart from routine daily volume.

Keyword alerts alone break down here. A single broad term returns hundreds of thousands of articles a month, most of them reprints of the same handful of developments. The job is to watch several theaters in parallel, get told when something changes, and keep a running narrative for each front.

What makes Middle East conflict news hard to monitor?

How do you set up a Signal to watch the region on perigon.io/home?

Which Articles and Stories filters scope a multi-theater beat?

When should you rely on Signals vs Articles vs Stories?

The sections below answer each in order.

Set up a Signal: perigon.io/home · Try the API: Articles sandbox · Compare plans: Signals pricing

What monitoring the region means in practice

There are two distinct jobs, and they map to two different tools.

A Signal is a continuous watch. You describe the region and the kinds of developments you care about in plain English, and it keeps working in the background - delivering Middle East war alerts in real time or as a scheduled briefing. That is the difference from a one-off search: you set intent once, and coverage comes to you.

Stories are the momentum layer. Perigon clusters related articles into a single evolving narrative, so an escalation that generates thousands of articles shows up as one trackable cluster you can follow over time. That is what makes regional conflict monitoring manageable across five theaters at once.

Use Signals for the live watch, Articles for precise historical queries, and Stories to see which fronts are actually accelerating.

Set up a Signal

Go to perigon.io/home and describe the beat in plain language - the assistant helps you refine scope, conditions, and how results are delivered (email, webhook, or a connector such as Slack). For a multi-theater region, name the fronts explicitly so nothing is dropped.

Copy-paste starting points:

Real-time escalation alert

Alert me to major escalations in the Middle East - airstrikes, ceasefire announcements, and cross-border attacks involving Israel, Gaza, Lebanon, Iran, or Red Sea shipping. Send each as it happens to my Slack channel.

Morning regional briefing

Every morning, summarize overnight developments across Israel-Gaza, Iran, Lebanon and Hezbollah, and Red Sea shipping. Group the summary by theater and include source links.

Diplomacy and de-escalation watch

Track statements, resolutions, and inspections from the UN Security Council and the IAEA related to the Middle East, and flag any ceasefire talks or nuclear-inspection developments.

Because escalations are event-like, Perigon delivers them in real time; a "summarize every morning" prompt is treated as a scheduled digest instead. You can run more than one Signal - a fast alert plus a calmer daily briefing is a common pairing.

Theaters and institutions to scope

A durable regional watch is organized by theater and by the institutions that shape de-escalation, not by whichever name is in today's headline. Evergreen fronts worth naming in a Signal or query:

Israel-Gaza - the highest-volume front, covering military operations, humanitarian access, and ceasefire cycles.

Iran - the nuclear file, proxy networks, and sanctions-linked tensions.

Lebanon and Hezbollah - cross-border exchanges and their spillover risk.

Red Sea shipping - attacks on vessels near one of the world's busiest maritime corridors (a security and freight-disruption angle - for crude-price and energy-market coverage, use a dedicated oil/energy watch instead).

Diplomacy - the UN Security Council and IAEA as standing institutions whose statements and resolutions often mark turning points.

Keeping these as roles and geographies - rather than one-off personalities - is what makes the Signal and the queries below reusable month after month.

Articles API recipes for the region

On the Articles API (/v1/all), build one query per theater and keep them narrow with Boolean q. Pair Israel, Gaza, or Hamas with escalation terms like strike, ceasefire, or offensive; pair Iran with nuclear, sanctions, or proxy; pair Red Sea or Houthi with vessel, shipping, or attack. Add category set to Politics to bias toward hard-news coverage, and sortBy set to date for the newest first.

To weight regional reporting, use sourceCountry for publisher geography or country for the story's associated country, and reach for language when you need Arabic-language or English-only slices. Stack from and to for a fixed window, or sortBy set to date with a rolling window for a live feed. Keep each theater as its own query so a spike in one front does not bury the others.

Stories API recipes for tracking momentum

The Stories API (/v1/stories/all) is where a multi-theater beat becomes readable. The same theater q you used on Articles returns clusters instead of individual articles, so you follow a development as one narrative rather than re-reading a hundred reprints. Sort by article count or recency to surface the fastest-moving fronts, and use an updatedFrom window to see which clusters are still active rather than cooling off.

The payoff is scale compression: broad theater keywords that return six-figure article counts collapse into a few hundred Stories clusters (see the numbers below). For how clustering groups related coverage into trackable narratives, see the news clustering guide; this page keeps the focus on applying it to the region.

When to use Signals vs Articles vs Stories

Goal	Use	Why
Be told the moment a front escalates	Signal (real-time)	Continuous watch, delivered to inbox, Slack, or webhook
A grouped daily read across theaters	Signal (scheduled)	One briefing, organized by front
Precise historical or filtered query	Articles API	Full Boolean, category, geography, and date control
Follow one development over time	Stories API	Clustered narrative and momentum, not raw article volume
See which theater is accelerating	Stories API	Compare cluster counts and recency across fronts

Beat scale at a glance

A few evergreen facts anchor why this beat needs structure: the region runs multiple simultaneous theaters, the UN Security Council carries standing authority over conflict resolution, the IAEA monitors nuclear activity, and the Red Sea remains one of the world's busiest shipping corridors - so a single week routinely produces parallel, fast-moving stories.

The live index shows the volume problem directly. Over the 30 days ending July 17, 2026, broad theater keywords returned very large article counts - roughly 345,000 for Iran-tensions terms, about 222,000 for broad Middle East conflict terms, and around 215,000 for Israel-Gaza terms - with Lebanon and Hezbollah near 88,000, Middle East coverage inside the Politics category about 77,000, regional institutions near 59,000, and Red Sea shipping around 13,000. (These are wide keyword slices, so treat them as relative signal, not precise tallies.)

The Stories layer is what makes that tractable. Across the same window, those slices collapsed into a few hundred narrative clusters each - on the order of 800 for Iran, 600 for Israel-Gaza, 570 for broad Middle East conflict, 250 for Middle East politics, 230 for Lebanon, 140 for regional institutions, and about 65 for Red Sea shipping. In other words, hundreds of thousands of articles became a few hundred stories to actually read.

Key takeaways

Middle East conflict news is a multi-theater beat - scope Israel-Gaza, Iran, Lebanon, and Red Sea shipping as separate fronts, not one keyword.

Set an AI Signal on perigon.io/home for real-time Middle East war alerts or a theater-grouped morning briefing.

Use the Articles API for precise Boolean, category, geography, and date queries per front.

Use the Stories API to turn six-figure article volume into a few hundred trackable clusters and see which theater is accelerating.

Organize the watch around evergreen theaters and institutions (UN, IAEA) so your Signals and queries stay reusable.

Get started: perigon.io/home · Signals pricing

Request News Api to index Publisher

Oleksyj Mokrousov — Mon, 27 Jul 2026 14:08:29 +0000

What to do when a publisher is missing from the news API

Perigon indexes hundreds of thousands of publishers, but sometimes the one outlet your product depends on - a niche trade site, a regional paper, or your own brand site - is not in the results yet. The fastest fix is usually to ask Perigon to add it, then confirm whether that is a support request or a plan upgrade.

This is a support and licensing guide, not an endpoint tutorial. It answers four questions:

Why is the publisher I need missing from the news API?

How do I ask Perigon to cover it - or add my own site?

How do live chat and email support work?

Which plans unlock request to index sources, an SLA, and a shared Slack channel?

Check what's indexed: Source Explorer · Ask for coverage or a demo: API pricing · Source docs: Sources and source groups

Why a publisher may be missing from the news API

Before you file a request, confirm the outlet is genuinely absent rather than filtered out. A source can be:

1) Indexed under a different domain or subdomain than the one you searched.

2) Excluded by your current query filters.

3) Present but low-volume, so it rarely surfaces.

Search the domain in Source Explorer or the Sources API first. If it truly is not there, you are looking at one of two different needs - and they route differently.

You want	This is	How to get it
Bundle domains that already exist into a reusable, named filter	Custom Source Groups (self-serve)	Source Groups API guide
Perigon to ingest a publisher that is not in the index yet	Request index for Sources (Commercial)	Request via support or sales

Put simply: Custom Source Groups organize sources Perigon already has, while Index request ask Perigon to add one it does not. This guide covers the second path. If the outlet is already indexed, skip the request and group it yourself.

How to request a publisher or add your own site

Adding a publisher is a human review step, not a self-serve API call, so the request goes through Perigon's support channels. Contact support, describe the outlet, and explain why your feed needs it. Perigon then evaluates the source for ingestion. First-party requests - adding your own news site or brand blog - follow the same process as third-party outlets.

Perigon can consider a range of publisher types, including:

1) Mainstream and wire outlets

2) Regional and local newspapers

3) Niche and trade publications

4) First-party sites you own and publish

Eligibility for new sources depends on your plan (see below). If you are on a lower tier and need custom ingestion, the request naturally becomes a sales conversation about moving to Commercial.

What to include in your request

A complete request is triaged faster. Include:

Domain - the exact publisher domain (for example example-tradedesk.com), plus any subdomains that carry articles.

Publication name - the readable outlet name so it can be matched or created.

Reason - the beat or use case, which helps prioritize the source.

Sample article URLs - two or three live links that show the crawl target and article structure.

Ownership - for your own site, confirm you own the domain and can grant publishing access.

How live chat and email support work

Perigon offers two ways to reach a human, and both work for a coverage request.

Live chat opens from the contact widget on every page and routes by intent:

Coverage requests - a missing publisher - go to support, where sources are evaluated.

Plan-upgrade questions, such as unlocking New Sources on Commercial, go to sales.

You can contact sales:

Or book a demo:

Email support is available on every plan for account and product questions, including coverage requests you would rather send as a written thread with your domain list attached.

Use live chat for quick questions ("Can you cover this outlet?", "Which plan do I need?") and email when you want a documented request. Either way, state clearly that you are asking to add a source so it is triaged correctly. Contact and demo booking also live on the pricing page.

Which plans unlock indexing of new sources that api do not have, SLA, and shared Slack

Email support is included on every plan, so account and product questions are never gated behind an upgrade. The heavier enterprise support and data features are Commercial-only:

New Sources indexing - Perigon adding publishers you request, including first-party sites.

Upgraded Support - a higher support tier beyond standard email.

SLA - a formal service-level agreement.

Shared Slack Channel - a direct support line between your team and Perigon.

Do not assume these ship on Free, Basic, or Plus. If your build needs custom ingestion, a guaranteed SLA, or a shared Slack line, that is the signal to talk to sales.

Plan and license matrix

This table is scoped to the support and licensing question this article answers, not the full usage matrix. Limits and pricing change, so treat the pricing page as the source of truth.

Feature	Free	Basic	Plus	Commercial
Data License / Who Qualifies	Anyone	Eligible Startups	Eligible Startups	All Businesses
License	Personal	Limited (Startup)	Limited (Startup)	Full Commercial
Email Support	Yes	Yes	Yes	Yes
New Sources Indexing	—	—	—	✓
Upgraded Support	—	—	—	✓
SLA	—	—	—	✓
Shared Slack Channel	—	—	—	✓

Commercial pricing is custom; contact sales rather than expecting a fixed number on the page.

FAQ

How long does it take to add a publisher? Perigon reviews each source case by case. In general it takes few days - from 12h to 48h.

Can I request a mainstream or niche trade outlet? Yes, both. The format is the same: domain and sample URLs.

Can I add my own news site or brand blog? Yes. First-party domains are handled like any other request - just confirm you own the site and can grant publishing access.

Should I contact support or sales? Start with support for the coverage question. If unlocking custom sources means upgrading, live chat routes the upgrade to sales, or you can start from the contact options on the pricing page.

Key takeaways

Confirm the outlet is truly missing, not just filtered out, before you file a request.

Custom Source Groups organize existing sources; New Index for Sources ask Perigon to add new ones.

Request coverage through live chat or email support - email is available on every plan.

New Custom Sources, Upgraded Support, an SLA, and a Shared Slack Channel are Commercial-only.

Include the domain, publication name, reason, and sample URLs, and check the pricing page for current plans.

Get started: Source Explorer · Sources and source groups · API pricing

Top Election Journalists: Who Covers Campaigns and Ballots (and How to Find Them)

Oleksyj Mokrousov — Mon, 27 Jul 2026 14:06:16 +0000

Why teams need an election journalist list

Election journalists sit at the center of campaign coverage, ballot fights, polling explainers, and voting-rights reporting. Keyword alerts for “election” or a last name pull sports “races,” foreign contests, and every photo-caption byline collision - while the political reporters who actually own campaigns, polls, or election administration stay hard to inventory.

Teams building outreach lists, citation trackers, or campaign-news products usually ask:

What does “top election journalists” mean when you build the list from an API?

How do you discover election and campaign reporters in the Journalists API?

Which example election journalists resolve cleanly for a shortlist?

When should you use Journalists vs People vs Sources for election coverage?

The sections below answer each in order. Full journalist-parameter depth belongs with the Journalists API guide when it ships; this page owns election-desk discovery - not a Signals monitor playbook and not a left/right ideology roster.

Try it: Journalists sandbox · Docs: Entities · Pricing: API pricing

What “top journalists for elections” means here

This is a methodology-backed discovery list, not a permanent ranking or endorsement.

For the election beat we:

Search journalists with q values such as election or campaign, scoped with category=Politics (and often country=us).

Prefer profiles whose titles or top topics point at campaigns, polls, voting, Congress, or US politics - and whose topSources match national or election desks.

Resolve ambiguous names carefully: many common bylines return near-matches; keep the row whose title, Twitter handle, and sources fit the election desk you mean.

Apply resolved journalistId values on Articles when you need sample bylines or a lasting campaign feed.

Exact topic=Elections or topic=Campaigns filters can return empty sets depending on how journalist topTopics are populated. In practice, q + category is the reliable discovery path for this beat; treat topic filters as optional polish after you confirm live hits in the sandbox.

US elections recur on a fixed calendar (federal contests every two years, plus continuous primary, ballot, and voting-rules coverage). That scale is why a reusable reporter shortlist beats rebuilding name search every cycle.

How to discover election journalists in the Journalists API

On the Journalists API (/v1/journalists/all), start with a discovery query, then tighten.

Goal	Filters to try
Broad election desk	q=election, category=Politics
US-focused + active posters	Add country=us, minMonthlyPosts (e.g. 5)
Campaign trail language	q=campaign, category=Politics, country=us
Polling / analytics desks	q with polling language, category=Politics
Known byline	name (exact-ish resolve), then confirm title and topSources
Stable product filter	Copy id into Articles as journalistId

Useful result fields for shortlists: id, name, title, topSources, topTopics, topCategories, avgMonthlyPosts, and Twitter handle when present.

On Articles (/v1/all), pass one or more journalistId values to pull that byline’s coverage. Add q=election (or campaign / ballot language) when you want election-framed hits only.

Use excludeJournalistId when a syndication-heavy byline floods the feed. Parameter reference: Entities.

Example election journalist shortlist

Resolved from live Journalists lookups. Prefer the id column in products; re-resolve when titles or desks change.

National campaign and politics desks

Name	Desk cue (from profile)	Primary outlets (topSources)	journalistId
Maggie Haberman	Senior Political Correspondent	nytimes.com	b7cc246d2e7a470a90b81f3d4ccad2ca
Jonathan Swan	Politics reporter	nytimes.com	97ce96fa1e36456c8a5c88c02900224c
Katie Glueck	National political reporter	nytimes.com	fe243583d666442fb4ccd85e5aed6b06
Reid Epstein	Politics Reporter	nytimes.com	25cb2840e4174b4a9c5bb2b72c424cf8
Annie Karni	Congressional Correspondent	nytimes.com	713c41110d664d02b02f9468eaa165b7
Nick Corasaniti	Domestic politics / voting	nytimes.com	4e7f0207d5664ee184f0a9b516d61836
Nate Cohn	Polls / US politics analytics	nytimes.com	fd2f250b31414dd8bf7ecd64bd3c880c
Robert Costa	Chief Election and Campaign Correspondent	cbsnews.com	a1ed83f0e9024614af5a8ac75606e8f5
Kate Sullivan	Campaign Embed	bloomberg.com	2d98292d26314fd1bcbd0cb6b86aba76

Election-title and polling discovery hits

These appeared when searching journalists with q=election and category=Politics - strong title signals for an election roster:

Name	Desk cue (from profile)	Primary outlets (topSources)	journalistId
Helen Coster	U.S. Presidential Election Correspondent	reuters.com	0f31d31dfd66430195eb005f7c04ee7c
Stephanie Kelly	U.S. Presidential Election Correspondent	regional / wire syndication	14f953f977bb42f5bb83d78cd39aa3e7
Ariel Edwards-Levy	Editor, Polling and Election Analytics	cnn.com	cce8e73d74ca4d8faf7d795439f39961
Stephen Ohlemacher	Election Decision Editor	regional TV news sites	38b074d3c62f463ab7401131425fee4c
Katie Bernard	Election administration / suburban politics	inquirer.com	18c20d8ddfce494d9f07731449d67dae

Name search is noisy: common names return managers, local TV hosts, or near-spellings. Keep rows where title + topSources + Twitter agree with the election desk you intend - drop zero-activity or off-beat collisions.

Sample coverage by these bylines

After you resolve IDs, Articles filtered with journalistId plus q=election show how that byline’s election-framed copy looks in the index - useful as a pattern check, not as lasting newsjack content. Refresh samples when you ship the product; volumes and syndication domains change.

Continuous Signals watches for Capitol Hill and leadership entities are a different job from a journalist roster - keep this page on byline discovery.

When to use Journalists vs People vs Sources

Need	Use	Why
Who wrote the story	Journalists API + Articles journalistId / author	Bylines and reporter profiles
Who the story is about	People filters (personName, personWikidataId)	Candidates, officials, surrogates as entities
Which outlets to allow	Sources / source groups	Publisher inventory, not individual reporters
Campaign narrative momentum	Stories (optional)	Clusters across many bylines - link Stories guides, do not re-teach here

Journalists answer “whose byline”; People answer “who was mentioned”; Sources answer “which publisher.” Election products often need all three - but this page starts with the reporter list.

Election coverage scale at a glance

A few facts that explain why a reusable election journalist shortlist beats keyword-only alerts:

US federal elections land every two years, with primaries, ballot measures, and voting-rules fights filling the gaps - the campaign desk never fully goes quiet.

Polling, election administration, and national politics each produce different bylines; one q=election alert mixes them without telling you who wrote the piece.

In the Articles index for pubDate 2026-06-16 through 2026-07-16 (US sources): about 820,000 Politics-category articles, and about 134,000 Politics hits that also match election - enough volume that byline allowlists matter for outreach, citation, and product feeds.

In the same window, “White House” and Congress keyword lanes sit around 150,000 and 170,000 articles respectively - adjacent politics firehoses that election desks still collide with unless you filter on reporters, people, or sources.

Round large counts in product copy; re-run stats when you ship so the window stays current.

Key takeaways

Build election journalist lists with Journalists discovery (q + category=Politics), not keyword article search alone.

Resolve names carefully; store journalistId for stable Articles filters.

Mix national campaign desks with explicit election-title and polling profiles so the shortlist is not one outlet only.

Use People for candidates and officials; use Sources when the unit of filtering is the publisher.

Re-run discovery when desks change - titles and topSources drift between cycles.

Get started: Journalists sandbox · Entities · API pricing

How Monitor US Politics News

Oleksyj Mokrousov — Mon, 27 Jul 2026 14:02:59 +0000

Why teams monitor US politics news

Monitoring US politics news isn't difficult because there are too many articles - it's difficult because keywords fail. Search for "Congress" and you'll get foreign legislatures, sports teams, opinion columns, and photo captions. Meanwhile, the leadership announcements, committee votes, and White House decisions that actually matter disappear into the noise.

Teams building a durable washington politics news or capitol hill news watch usually ask:

How do you monitor US politics news?

How do you resolve White House and Congress leadership before filtering articles?

How do Articles API and Stories API recipes keep us government news and election coverage precise?

When should you use Signals vs Articles vs Stories for US politics?

The sections below answer each in order. Entity parameter depth lives in Entities; this page owns the US politics Signals + institution playbook.

Try it: perigon.io/home · Articles sandbox: sandbox · Entities docs: Entities · Pricing: Signals pricing

What “monitor US politics” means in practice

A continuous watch for us policy news is not the same as one search on election night. Signals keeps a briefing lane running while leadership, bills, and campaigns evolve. Articles pins specific people, topics, and US source/geography filters for product feeds. Stories groups reprints when a floor fight, White House announcement, or campaign spike floods outlets at once - use velocity when you care that a narrative is accelerating, not only that one URL appeared.

Trade policy, sanctions, and agency enforcement each deserve their own Monitor draft when that desk is the product; keep this page on federal politics institutions and leadership.

How to monitor US politics news with Signals with perigon.io

Open perigon.io/home and describe the watch in plain language. Signals turns that ask into a continuous briefing so you are not rebuilding the same political news monitoring query every morning.

Name the institutions (White House, House, Senate), the people who define the beat for your desk, and the output shape (bullets, risks first, nonpartisan summary). Refine after the first run: tighten to legislation vs campaign rhetoric, or to leadership-only mentions.

Copy-paste Signal prompts

White House and executive agenda

Monitor US White House and executive-branch coverage affecting domestic policy and Congress relations. Prefer major national publishers. Summarize in short bullets for a policy reader; flag contested claims and distinguish official statements from opinion columns.

Capitol Hill / Congress watch

Track US House and Senate news: floor votes, leadership statements, committee markups, and Speaker or Majority Leader mentions. Focus on legislation and procedural fights. Exclude sports “House” and foreign parliament noise unless clearly about the US Congress.

Leadership and campaign spillover

Watch news that meaningfully mentions US political leadership (President, Vice President, Speaker of the House). Ignore photo-caption name-checks and unrelated people with the same surname. Note interviews, conference cancellations, and intra-party schedule fights that change Capitol Hill narrative.

These prompts are evergreen: they describe ongoing beats, not a single week’s headlines. Swap or add leaders when your desk’s org chart changes - keep Signal wording on roles plus confirmed people IDs from the table below.

Resolve White House and Congress leadership before you filter

US politics monitoring works best when people are resolved first. Name search alone surfaces athletes, musicians, and family members with the same string.

Canonical people (from People lookup)

Role (evergreen)	Name	Use in filters	Resolved value
President of the United States	Donald Trump	personWikidataId	Q22686
Vice President of the United States	JD Vance	personWikidataId	Q28935729
Speaker of the House	Mike Johnson	personWikidataId	Q19880665

When you re-run People search for “Donald Trump,” keep Q22686 - not Donald Trump Jr. (Q3713655) or family matches. For “JD Vance,” keep Q28935729 (Vice President) - not unrelated JD / Vance hits. For “Mike Johnson,” keep Q19880665 (Speaker) - not hockey, music, or football collisions.

On the People API (/v1/people/all), refresh lookups when leadership changes; keep Signal prompts and article filters on these Wikidata IDs. Param reference: Entities.

Example coverage snapshot

Coverage pinned to these entities often looks like leadership schedule fights or Congress reacting to a White House policy frame - for example:

Article-style hits on Speaker-linked House lanes (e.g. House leaders backing a White House framework) from national or regional DC-facing publishers such as insidenova.com.

Story-style clusters where VP and House GOP calendars collide (e.g. a canceled House Republican Conference appearance tied to conference and election-integrity fights) with several outlets reprinting the same narrative.

Use overviews like those as pattern checks only - refresh samples when you build the product; do not treat one week’s cluster as lasting newsjack content.

Articles API recipes for White House, Congress, and elections

On the Articles API (/v1/all), pin people with personWikidataId rather than bare last-name q when you need white house news, congress news, or senate news without surname collisions.

Goal	Start with	Optional add-ons
Core us politics news / dc politics news	category or topic Politics; sourceCountry us when you want US publishers	excludeLabel for Opinion when you want harder news
White house news / president lane	personWikidataId Q22686	Short q for bill, veto, executive order when event type matters
VP / administration spillover	personWikidataId Q28935729	Combine with Politics category
House of representatives news / Speaker lane	personWikidataId Q19880665	q for House, Speaker, or conference when narrowing floor fights
Us election news / us campaign news	Politics topic + election / primary / ballot q	People pins for candidates your desk tracks; Stories when reprints explode
Fresh poll	addDateFrom from last checkpoint	sortBy on add date for ingest-style feeds

Prose example: pass personWikidataId set to Q22686 for the presidential lane, or Q19880665 when the Speaker defines the House story, add Politics category or topic, and poll with addDateFrom so each run only returns what is new since the last check. For partisan news filter workflows, prefer entity pins plus label excludes over hoping a keyword encodes “left” or “right.”

Public US left / right / center source groups can narrow publisher skew when your product needs a media-balance slice - discover and apply groups via Sources docs; do not rebuild group CRUD here.

Stories API recipes for politics story tracking

When floor fights, White House announcements, or campaign spikes reprint across dozens of outlets, Stories (/v1/stories/all) keeps politics story tracking on narratives instead of every mirror URL.

Pass the same personWikidataId values (for example Q28935729 for VP-centered clusters). Sort or filter by recent updates when you care that a Capitol Hill storyline is still moving. Full clustering and velocity theory lives in the Stories clustering guide - keep this page on US politics filters, not a second Stories textbook.

When to use Signals vs Articles vs Stories for US politics

Need	Prefer
Daily us politics news briefing without writing queries	Signals on perigon.io/home
Embed Capitol Hill feeds in a product	Articles API with personWikidataId + Politics filters
Leadership-sensitive policy or IR lanes	Confirmed Wikidata IDs above; optional Signal for narrative
“Is this Washington story accelerating?”	Stories with the same people / Politics scope
General entity param reference	Entities docs

US politics at a glance: why the beat stays noisy

A few scale facts that keep political news monitoring from sounding like a blank keyword alert:

A single Congress typically sees thousands of bills introduced; only a small fraction become law - the news firehose is the debate, not the final statutes.

Capitol Hill runs through hundreds of committees and subcommittees, each with its own markup, hearing, and leak cycle.

The executive branch issues dozens of directives and executive actions in busy stretches - White House messaging then collides with House and Senate reaction within hours.

Federal elections hit every two years (House all seats; Senate in classes), so us campaign news never fully leaves the wire even in “off” years.

The White House maintains a near-daily press briefing cadence - which is why white house news and capitol hill news need separate lanes in Signals and in API filters.

What that looks like in the index (30 days, pubDate 2026-06-15–2026-07-15, US sources): about 820,000 Politics-category articles; roughly 150,000 with “White House” in the query and 170,000 matching Congress; about 130,000 Politics hits that also mention elections. Leadership lanes show why person filters matter: on the order of 370,000 articles linked to the President (Q22686), about 42,000 for the Vice President (Q28935729), and about 11,000 for the House Speaker (Q19880665) in the same window - same beat, very different volumes, which is why Signals and API watches should separate White House, Congress, and leadership pins instead of one catch-all keyword.

Key takeaways

Monitor US politics news with Signals prompts on /home for continuous briefings, then mirror the beat in Articles and Stories.

Resolve leadership with Wikidata IDs: President Q22686, VP Q28935729, Speaker Q19880665 - skip surname collisions.

Combine people pins with Politics topic/category, US source scope, and addDateFrom for product feeds.

Use Stories for politics story tracking when reprints explode; keep velocity theory in the Stories guide.

Keep SEC, trade/tariffs, and single-company watches in their own Monitor drafts.

Get started: perigon.io/home · Entities docs · Stories clustering guide · Signals pricing

Build Custom News API Publisher Lists and Source Collections

Oleksyj Mokrousov — Mon, 27 Jul 2026 13:57:15 +0000

Custom publisher lists break when they live in every query

Hard-coding twenty domains into sources param works once. It fails when an analyst swaps a publisher, a competitor desk adds three trade outlets, or two products disagree on which regional papers belong in the allowlist. Teams then paste different domain strings into Articles, Headlines, Stories, and cron jobs - and alert quality drifts because the filter is no longer one object.

That is the job of a source groups API: turn a chosen publisher collection into a named, reusable filter. Perigon already ships public bundles (for example top100, top25finance, top50tech). This guide covers the source group CRUD surface for your own custom source lists, how private source groups and public source groups resolve, and how to apply them for cleaner monitoring.

What is a source groups API?

How do source groups improve repeatable filtering versus pasting sources param every time?

How do private and public source groups work for publisher collections?

How do custom publisher collections improve monitoring and alert quality?

Try it live: Sources sandbox · Read the docs: Sources and source groups · Compare plans: API pricing

What is a source groups API?

A source groups API manages named collections of publisher domains. Each group has a stable name (what you pass as sourceGroup on search), optional displayName and description, and a domains list. Once the group exists, article and story searches reference the name, not the raw domain string.

Perigon exposes this under /v1/api/sourceGroups:

Operation	Endpoint	Job
Create	POST /v1/api/sourceGroups	New org-owned group with name + domains (required); optional displayName, description
List	GET /v1/api/sourceGroups	Org-owned groups plus publicly visible bundles; filter by name or domain
Get	GET /v1/api/sourceGroups/{id}	One org-owned group by integer id
Resolve	GET /v1/api/sourceGroups/resolve	Map names → group records (private preferred)
Update	PATCH /v1/api/sourceGroups/{id}	Partial update of owned groups
Delete	DELETE /v1/api/sourceGroups/{id}	Remove an owned group

This page owns that lifecycle. Publisher discovery (find a domain, visits, paywall, geo) lives on the Sources API (/v1/sources/all) - see the News Source API post for the directory cookbook, and Sources docs. Vertical inventories like healthcare trade pubs or top25finance live in those compare posts, not here.

How source groups improve news filtering

Without groups, every feed embeds a domain allowlist. With groups, search params stay short and reusable publisher filters stay in one place.

Approach	What you maintain	Drift risk
Repeated source=a.com,b.com,...	Domain string in every client	High - each caller copies a slightly different list
Named sourceGroup=my-desk	One group record + search param	Low - patch the group; queries keep the same name

Typical flow:

1) Discover candidate domains with the Sources API (or Source Explorer) when you need metadata.

2) Create a custom source list with POST /v1/api/sourceGroups and your domains array (1–5000 domains).

3) Resolve or list by name when another service only has the label.

4) Apply sourceGroup on Articles (/v1/all), Headlines, Stories, or Sources to scope results to that collection.

5) On Articles, use excludeSourceGroup when you want everything except a noisy bundle.

You can still use bare source / excludeSource for one-off domain tweaks. Groups are for collections you will reuse.

Pass excludeSourceGroup when you need a publisher denylist bundle on Articles only. Stories and Sources accept sourceGroup for include-side scoping; Stories do not support group excludes the same way Articles do. For industry packs already published as public names, start there and customize privately - see the healthcare trade publications and top25finance posts for those inventories.

Private and public source groups for publisher collections

Public source groups are Perigon-maintained curated source bundles (for example top10, top100, top500English, top25crypto, top25finance, top50tech, top100sports, and US left / right / center packs). Anyone with API access can pass those names as sourceGroup. List can return publicly visible groups alongside your own.

Private source groups are created under the organization tied to your API key. Create, get-by-id, patch, and delete only apply to groups your org owns. That is where analyst approved sources, competitor publisher list subsets, and regional source collection forks belong.

Resolve is the important rule: GET /v1/api/sourceGroups/resolve with one or more name values returns, for each name, your organization's private group if one exists; otherwise the matching public group. That lets a product use a shared public label like top50tech until you create a private group with the same name - after which resolve (and your mental model for that workspace) prefers the private definition. Keep private names intentional so you do not shadow a public bundle by accident.

Workspace UI under Settings → Source Groups can create the same objects for teams that prefer a console; the API is the programmable path for CI and multi-product orgs. Long lists you cannot maintain yourself can also be requested from Perigon support - the same collection model applies.

How custom publisher collections improve monitoring and alert quality

Alerts and monitors fail noisily when the publisher set wanders. A stable group name is a contract between the research desk and the pipeline.

Pattern	Collection idea	Search habit
Analyst approved	Domains the desk signed off on	sourceGroup = private name on every poll
Competitor desk	Tier-1 + relevant trade outlets only	sourceGroup include, or Articles excludeSourceGroup for spam packs
Regional fork	Public national pack minus irrelevant wires	Private group copied from a public starting set, then patched
Product vs research	Two private names, same topic keywords	Same q / company filters; different sourceGroup

Updating domains is a PATCH on the group id, not a redeploy of every query string. List with domain when you need to find which workspace source groups already contain a publisher. Delete when a product is retired so resolve does not keep pointing at stale private names.

Inspection tip: to see membership of a named bundle without re-teaching Sources here, call Sources with sourceGroup set to that name - that is directory view of members. Lifecycle changes still go through /v1/api/sourceGroups.

Source group CRUD fields and list filters

Create body

Field	Required	Notes
name	Yes	Stable slug used as sourceGroup on search
domains	Yes	Array of publisher domains
displayName	No	Human label in UI
description	No	Desk notes / ownership

List query

Param	Role
name	Filter groups by name
domain	Find groups that include a domain
sortBy / sortOrder	Required sort controls on list
page / size	Pagination

Resolve query: name (up to 100 names) → private-first records.

Use cases

Analyst-approved allowlist

Create a private group with the domains research marked as trustworthy for a product. Poll Articles with that sourceGroup plus your topic or company filters. When analysts add a site, patch domains - alert jobs keep the same group name.

Competitor publisher list

Build a tight publisher allowlist for competitor coverage, or keep a wide search and attach excludeSourceGroup on Articles for bundles you never want in the feed. Persist the exclude name the same way you persist the include name.

Regional source collection

Start from a public national or language pack name for smoke tests, then create a private regional collection with only the markets you serve. Resolve tells services which definition wins for a given name in your org.

Industry packs

Pass public names such as top25finance or healthcareTradePublications when the maintained pack is enough. Domain-by-domain justification belongs in the vertical posts; this API topic stops at “create or resolve the collection, then apply the name.”

When to use groups vs Sources vs bare source

Need	Use
Find or rank publishers by visits, geo, paywall	Sources API (/v1/sources/all)
Reuse a domain set across products and jobs	Source Groups API + sourceGroup
One-off include or exclude of a few domains	source / excludeSource
Industry SERP + curated inventory write-up	Vertical trade-pub / finance posts
Narrative / velocity monitoring	Stories (and Breaking) guides - same sourceGroup name if helpful

Compose with other filters

sourceGroup is a publisher gate, not a topic engine. Stack it with q, company or people filters, dates (from / to / addDateFrom), taxonomy, category, and topic the same way you would with source. Keep this article’s examples group-centric; parameter cookbooks for entities and taxonomy stay in those pillar posts.

API plans

Source filtering and curated public groups are available across API plans; private group capacity and volume limits follow your tier. Confirm current limits on API pricing.

Key takeaways

The source groups API (/v1/api/sourceGroups) owns create, list, get, resolve, patch, and delete for custom source lists.

Resolve prefers your org’s private source group over a matching public source group for the same name.

Apply collections with sourceGroup (and Articles excludeSourceGroup) - do not paste long domain strings into every client.

Use Sources for publisher metadata; use vertical posts for industry domain inventories; use this page for source group CRUD and resolution rules.

Get started: Sources and source groups · API reference · Sources sandbox

Keyword vs Google Taxonomy: Fix Noisy Vertical News Alerts

Oleksyj Mokrousov — Sat, 25 Jul 2026 10:23:06 +0000

Your industry alert is still a string match

A “banking desk” built on q = bank will happily ingest river banks, blood banks, data banks, and robbery blotter. A “rock feed” on q = rock will mix geology, wrestling, and cocktail recipes with actual Rock Music coverage. The channel looks productive; the product is not on-vertical.

This page is a bakeoff diagnostic for noisy keyword desks. It is not the full Google taxonomy filter cookbook (exact path vs prefixTaxonomy, Stories, classify). That lives on Perigon’s News API filter by Google taxonomy guide - link out when you are ready to wire the params.

Why do vertical keywords inflate alerts?
How large are the gaps for bank, fund, and rock?
When should you use taxonomy vs Perigon category vs topic?
What bakeoff should you run before shipping a desk?

Why vertical keywords inflate alerts

Keywords match tokens. Vertical desks need aboutness. Google Content Category paths (V2) on Perigon articles describe industry and content family - Banking under Finance, Rock Music under Arts & Entertainment - so a filter can mean “this kind of story,” not “this substring appeared.”

Habit	What you get
q = bank / banking	Central banks, rivers, features named “bank,” crime, metaphors
q = fund	Mutual funds plus “fund a project,” fundraisers, verb uses
q = rock	Music plus geology, sports nicknames, food, idioms
Taxonomy path for the vertical	Articles classified into that Google hierarchy

You still stack dates, sources, and companies. The fix is choosing the right aboutness filter first.

Live bakeoff: bank, fund, rock (30 days)

Articles counts for pubDate 2026-06-25 through 2026-07-25 (round in product copy; huge open queries are order-of-magnitude):

Desk intent	Keyword filter	About how many	Taxonomy / structured filter	About how many
Banking vertical	q = bank	~988,000	taxonomy = /Finance/Banking/Other	~363,000
Banking (wordier keyword)	q = banking	~259,000	prefixTaxonomy = /Finance/Banking	~363,000
Funds vertical	q = fund	~695,000	taxonomy = /Finance/Investing/Funds	~398,000
Rock music vertical	q = rock	~341,000	taxonomy = /Arts & Entertainment/Music & Audio/Rock Music	~210,000

Read the table carefully. Taxonomy is not always the smallest number - q = banking (~259k) is below Banking taxonomy (~363k) because many banking stories never use the token “banking.” The failure mode is different: keywords miss on-vertical pieces and include off-vertical tokens. Taxonomy stays on the Google Banking branch either way.

Keyword bank (~988k) is still ~2.7× the Banking taxonomy slice - that gap is mostly noise and adjacent senses. Keyword fund (~695k) vs Funds path (~398k) shows the same pattern. Keyword rock (~341k) vs Rock Music (~210k) cuts a large geology/idiom/sports tail while keeping tour and album coverage the music desk wants.

For a wider finance firehose, prefixTaxonomy = /Finance was about 3.4M in the same window - useful as a branch monitor, not a tight desk. Pair a narrower leaf path when alerts must stay readable.

Taxonomy vs category vs topic (pick one job)

Perigon exposes three related dimensions. Mixing them up recreates keyword chaos with nicer names.

Filter	What it is	Use when
taxonomy / prefixTaxonomy	Google Content Category paths	Industry / content-family desks (Banking, Rock Music, Health Conditions)
category	Perigon broad themes (Finance, Tech, Health, …)	Fast dashboard buckets; e.g. category = Finance was ~3.5M in this window
topic	Granular Perigon topics	Storyline types - e.g. topic = Cryptocurrency ~187k vs q = cryptocurrency ~89k (topic can out-recall a thin keyword)

Rule of thumb: Google path when the desk is an industry tree; Perigon category for coarse theme chrome; topic when you need a named storyline slice. Stack carefully - do not OR three overlapping definitions of “finance” and call it precision. Deep param behavior stays on the taxonomy filter guide linked above.

Bakeoff checklist before you ship a vertical alert

Write the desk intent in one sentence (“Rock Music coverage,” not “anything with rock”).
Run q = token and the matching Google taxonomy (or prefixTaxonomy) for the same from/to window.
Spot-check twenty titles from each list - count off-vertical hits and obvious misses.
If the keyword is quieter but incomplete (like q = banking vs Banking path), prefer taxonomy and accept the larger on-vertical set.
Only then add source packs, companies, or labels - aboutness first, polish second.

Key takeaways

Vertical q filters are string matches; taxonomy paths are aboutness filters for industry desks.
Live gaps matter: bank ~988k vs Banking taxonomy ~363k; rock ~341k vs Rock Music ~210k (30 days ending 2026-07-25).
Quieter keywords are not always better - banking can under-recall vs the Banking path.
Use taxonomy for industry trees, category for broad themes, topic for granular storylines.

Place-Name Keywords vs Geo Filters for Local News

Oleksyj Mokrousov — Sat, 25 Jul 2026 10:12:39 +0000

Your “local” alert is probably a keyword in disguise

Many desks build “Chicago news” or “Portland coverage” by stuffing the city into a keyword field. That habit creates false confidence: the feed looks busy, the Slack channel never sleeps, and half the hits are the wrong market, a person named Austin, or a national wire that mentioned the city once.

This page is a diagnostic, not a full geography-param cookbook. It shows five failure modes with live volume gaps, then points you to structured filters. For the complete local news API surface (county, radius, Stories, Sources), use Perigon’s Local news API search guide.

What goes wrong when the city is only a keyword?
How big is the gap for ambiguous markets (Portland, Austin, Springfield)?
How do event-city and newsroom-city filters differ (Chicago)?
What should you change in the alert job tomorrow?

Try it: Articles sandbox · Docs: Local news · Plans: API pricing

Failure mode 1: Ambiguous city names (the Portland problem)

Portland is not one market. A keyword match cannot tell Oregon from Maine - or from cement, travel, and sports noise that shares the string.

Live Articles counts for pubDate 2026-06-25 through 2026-07-25:

Filter	About how many articles
q = Portland	~67,000
city = Portland + state = OR	~6,200
city = Portland + state = ME	~1,300

Keyword Portland is roughly 10× Oregon event-scoped volume and 50× Maine. If your “Portland desk” used q, most of the firehose was not your DMA.

Failure mode 2: Person and brand collisions (Austin)

Austin is a capital city and a common given name. Keyword search pulls both.

Filter	About how many articles
q = Austin	~143,000
city = Austin + state = TX	~11,000

Texas event geography is about 13× quieter than the keyword - still busy, but no longer every headline that mentions someone named Austin.

Failure mode 3: Many towns, one string (Springfield)

Springfield is a classic trap: Illinois capital, plus cities in other states, plus fiction and sports nicknames.

Filter	About how many articles
q = Springfield	~24,000
city = Springfield + state = IL	~2,200

If the job is Springfield, Illinois government or plant news, the keyword feed is mostly other Springfields and incidental mentions.

Failure mode 4: Event city vs newsroom city (Chicago)

Even when the place string is unique enough, where the story happened and where the publisher sits are different questions. Keyword Chicago mixes both - and everything else.

Filter	About how many articles
q = Chicago	~321,000
city = Chicago + state = IL (event / story place)	~60,000
sourceCity = Chicago + sourceState = IL (publisher based there)	~144,000

Event-scoped Chicago is far below the keyword firehose. Newsroom-scoped Chicago is larger than event-scoped - national and metro outlets headquartered in Chicago cover many non-Chicago events. Pick the axis on purpose: city council and weather emergencies → event city / state; hyperlocal reader apps and DMA ad products → sourceCity / sourceState. Combining both is a third product (events in a county from in-state publishers) - details in the local news guide linked above and location & geo docs.

Failure mode 5: Treating volume as quality

A keyword city alert “working” usually means it is loud. Use a one-week bakeoff before you ship:

Run q = CityName and city + state side by side for the same from/to window.
Spot-check twenty titles from each - count wrong-market and name-collision hits.
If you need outlets in the market rather than events there, swap in sourceCity / sourceState (or discover publishers on the Sources API first).
Only then add topic, company, or radius - geography first, keywords second.

Radius feeds (lat / lon / maxDistance) belong when the user or plant is a point on a map, not a city string - again owned by the full local guide, not this diagnostic.

What to change in the alert job tomorrow

If your job looks like…	Stop doing	Start doing
“Portland OR desk” via q	Keyword Portland	city + state = OR
“Austin CI” via q	Keyword Austin	city + state = TX (+ company filters)
“Springfield IL plant”	Keyword Springfield	city + state = IL (or county)
“Chicago hyperlocal app”	Keyword Chicago	sourceCity / sourceState, or Sources then allowlist
“Stories in the metro”	Article keyword flood	Stories with city / state (see local guide)

Key takeaways

Place-name keywords are not local news monitoring - they are string matches with market collisions.
Live gaps are large (e.g. Portland q ~67k vs OR ~6.2k vs ME ~1.3k; Austin q ~143k vs TX ~11k in 30 days ending 2026-07-25).
Chicago shows event city (~60k) and sourceCity (~144k) answer different product questions - neither equals keyword Chicago (~321k).
Fix the geography axis first; leave the full param and radius cookbook to Perigon’s Local news API search guide.

Get started: Articles sandbox · Local news docs · Local news API search guide · API pricing

News Integration: RSS Polling vs Structured Feeds

Oleksyj Mokrousov — Sat, 25 Jul 2026 09:46:35 +0000

Product news features hit a wall that feed readers never see

Shipping a news integration - a Slack alert bot, a customer dashboard tile, an AI agent that cites today’s coverage - feels easy if you start with RSS polling. Grab a few XML feed URLs, cron every 15 minutes, parse title/link/date, done. That pattern works for humans in a feed reader. It falls apart the moment the same stream has to power a product: dedupe across outlets, filter by company or person, push events into your system, or keep latency predictable under load.

This piece is for builders. If you only need a personal reader decision (when Google News / publisher RSS is enough vs curated trackers), start with Perigon’s Google RSS vs data feeds guide instead - that page owns the human-monitor angle. Here the job is different: news API for products, production news pipelines, and why XML news feeds stop being an architecture.

The sections below answer:

What does RSS polling look like inside an app stack?
Where do XML news feeds break product pipelines?
What does a structured news integration look like instead?
When should you keep RSS vs move to feeds, Signals, or the API?
How do live coverage volumes change the design?

Try queries: Articles sandbox · Push events: Signals webhooks · Plans: API pricing

What RSS polling looks like in an app stack

RSS polling is a client-side loop: store feed URLs, HTTP GET on a schedule, parse channel items, upsert by link or GUID, notify users. Many teams also scrape Google News–style query feeds the same way. The contract is thin - usually title, link, summary, published date - and each URL is its own silo.

In a product that means:

Layer	Typical RSS approach	Product friction
Ingest	Cron + XML parse	Poll windows miss bursts; every publisher is a custom URL
Identity	Link / GUID	Same story across 20 outlets → 20 rows
Filter	Keyword rules in your code	No stable company or person IDs
Delivery	Your own queue after poll	You own retries, backlog, and quiet hours
Scale	Add more feed URLs	Coverage sprawl without shared schema

None of that is wrong for a hobby bot. It is a weak foundation for a structured news feed your customers rely on.

Where XML news feeds break product pipelines

Four failure modes show up once the feature leaves a side project.

Volume without structure. In the Perigon index for pubDate 2026-06-25 through 2026-07-25, a plain q of cybersecurity matched about 138,000 articles. OpenAI as a keyword hit about 167,000; resolving the same company via companyId still returned about 128,000 articles but only about 402 Stories clusters. An RSS inbox treats every reprint as a new item. A product that alerts on “OpenAI news” without clustering or entity filters drowns users.

Keyword ≠ entity. The same 30-day window: ChatGPT as keyword ~80,000 articles; ChatGPT plus the OpenAI companyId ~33,000. Sam Altman via person Wikidata Q7407093 ~17,500 articles / 61 Stories. RSS has no first-class companyId or personWikidataId - you reinvent that with brittle string rules.

Ticker and brand noise. companySymbol NVDA alone was about 178,000 articles in that window; keyword NVIDIA about 163,000. High-volume names need allowlists, labels, and source packs - not another XML URL in the poller.

Push vs pull. Products want webhook news alerts into Slack, a CRM, or an internal bus. RSS is pull-only. You own the scheduler and the lag. Structured monitors that emit JSON events fit product SLAs better than “we polled 40 feeds at :00 and :15.”

What a structured news integration looks like

A production news integration usually separates three jobs RSS tries to do alone:

Retrieve - queryable articles and stories with filters (company, person, source group, dates), not only subscribed XML URLs.
Monitor - a durable watch (Signal / curated feed) for the beat your product cares about.
Deliver - email, connectors, or webhooks into your systems when something matches.

On Perigon that maps to the Articles / Stories APIs for retrieval, Signals and Discover feeds for ongoing trackers, and Signals webhooks for push into your stack. The human-facing “is RSS enough?” decision stays on the RSS vs data feeds guide linked above; this page assumes you already know you are building software.

Capability sketch for builders:

Need in the product	RSS polling	Structured feed / API path
Stable company or person filter	DIY keywords	Entity IDs on search and monitors
One narrative, many reprints	Manual dedupe	Stories / clusters
Real-time push to your app	Build it	Webhooks and connectors
Shared schema for UI and agents	Title + link	Structured article fields
Desk theme without URL sprawl	Folder of feeds	Curated / Signal-backed feeds

For ad-hoc query design (Boolean q, sources, pagination), use the practical news API guide - this post does not re-teach those params.

When to keep RSS vs when to move

Keep RSS polling when the feature is a personal or internal reader, the outlet list is short and stable, and nobody outside that reader needs a shared schema or push SLA.

Move to structured feeds / Signals when the same beat must power a customer-facing surface, a team channel, or an automation - and you need multi-source coverage without babysitting feed URLs.

Move to the News API when the product needs programmable search, custom filters, historical windows, or agent tooling on top of the index - not only a prebuilt tracker.

A practical migration for an app team:

Inventory which RSS URLs actually drive product behavior; drop vanity polls.
Map each job: awareness UI vs alert vs AI grounding.
Parallel-run: keep the poller for a sprint while a Signal-backed feed or API query covers the same beat; compare misses, duplicates, and latency.
Graduate push paths to webhooks; keep RSS only where a human still wants a classic reader.

Key takeaways

RSS polling is a fine reader pattern and a fragile news integration for products.
Live volumes (e.g. ~128k OpenAI-company articles vs ~402 Stories in 30 days ending 2026-07-25) show why apps need entities and clusters, not more XML URLs.
Split retrieve / monitor / deliver: API + Signals/feeds + webhooks beat a single cron parser.
For “is RSS enough for a human desk?” use the Perigon RSS vs data feeds guide; for shipping product pipelines, design for structured feeds and push delivery.

Get started: Articles sandbox · Discover feeds · Google RSS vs Perigon data feeds · API pricing

44 Best Manufacturing News Sources in 2026

Oleksyj Mokrousov — Sat, 25 Jul 2026 09:37:15 +0000

AI top-8 industrial source lists miss most of the beat

Teams buying manufacturing news, factory automation news, and industrial automation news feeds often start by asking an LLM for the “best” industrial trade publications. That is a weak foundation for production monitoring. GPT, Claude, and Gemini each invent a short industry news sources roster - they disagree on most names, skip whole lanes (supply chain trade desks, UK construction press, additive manufacturing, pumps and reliability), and still feel complete because eight domains fit in a chat reply.

Do not trust that allowlist. A brainstorm is not a curated B2B manufacturing media pack. Perigon’s industrialTradePublications source group (ID 725, 44 domains) is built for the full industrial picture: manufacturing leadership, plant engineering, controls, machinery, robotics, process ops, and adjacent supply chain trade news - then applied as one reusable sourceGroup on search.

Rather than maintaining dozens of publisher filters yourself, Perigon groups related publications into reusable source groups. Instead of listing every manufacturing publication in each API request, you can reference a maintained group that evolves over time.

What fuller vertical manufacturing news coverage looks like in industrialTradePublications source group?

How to monitor machinery news, plant ops, and automation with that source group

How to filter manufacturing news by source, company, topic, category, location, and date

Try it live: Sandbox · Docs: Sources and source groups · Plans: API pricing

Other vertical packs (different SERPs): healthcare trade pubs · top25finance. Creating private forks: Sources and source groups - this page applies the public industrial pack only.

Why you should not trust AI for industrial trade publication allowlists

Prompt three models for top industrial trade publications with domains. Across ChatGPT, Claude, and Gemini:

Only two outlets appear on all three lists: IndustryWeek (industryweek.com) and Automation World (automationworld.com).

Everything else is a bias: Claude skews assembly / ENR construction / American Machinist; Gemini pulls Manufacturing Dive, power, chemicals, and packaging titles; GPT favors machine-shop and UK engineering picks.

Overlap is thin. Two-model agreement reaches a few more (manufacturing.net, plantengineering.com, controleng.com) - still nothing like a full niche industrial sources set.

What AI does	What breaks in production
Returns a neat “top 8”	Misses 30+ trade publication news domains you may already need
Sounds authoritative	Different models → different desks → different alert quality
Mixes brainstorm + “also include” extras	No stable name your Articles / Stories jobs can keep forever

Claude even warns that “industrial” shifts by sub-sector (aerospace, materials handling, oil and gas). That is the point: an LLM answer is a partial map. For plant engineering news, factory automation news, and industryweek-class leadership coverage plus the rest of the floor, you need a maintained sourceGroup - not a chat paste.

Quick split (domains once):

Claude-only top-8 → assemblymag.com, machinedesign.com, ien.com, enr.com, americanmachinist.com.

Gemini → manufacturingdive.com, packworld.com, powermag.com, chemengonline.com.

GPT-only → mmsonline.com, processingmagazine.com, theengineer.co.uk.

Treat those as research signals that AI is incomplete - not as three competing truths.

The fuller picture: industrialTradePublications group with 44 domains

Field	Value
Name	industrialTradePublications
Display name	Industrial Trade Publications
Source group ID	725
Size	44 domains
Scope	Trade sources covering manufacturing, automation, machinery, and industrial operations

Pass sourceGroup=industrialTradePublications on Articles (/v1/all), Headlines, or Stories. Inspect members via Sources with the same group name - without dumping every domain into this article twice.

What Perigon keeps that AI top-8 lists drop

Durable AI shorts that do belong in a serious pack are already here (IndustryWeek, Automation World, Manufacturing.net, Plant Engineering, Control Engineering, plus many Claude/Gemini/GPT singles). The fuller picture is the lanes chat lists routinely skip:

Daily manufacturing + supply chain trade news - e.g. Manufacturing Dive and supply-chain trade desks (manufacturingdive.com, supplychaindive.com, supplychaindigital.com, …) beyond any GPT top 8.

Construction / owners / UK build press - more than a single ENR mention (constructionowners.com, constructionnews.co.uk, theconstructionindex.co.uk, …).

Robotics, AMR, digital and additive manufacturing roboticsandautomationnews.com, advancedmanufacturing.org, manufacturingdigital.com, metal-am.com, and peers.

Process, food engineering, pumps, reliability, controls - plant-floor and CPI-adjacent titles (food engineering, pumps and systems, reliable plant, Control Global, chemical engineering) so process manufacturing news is not one magazine guess.

Associations and branded manufacturing media - SME and manufacturing-today / tomorrow style industry news sources models bury under “optional.”

Honest gaps: GPT’s processingmagazine.com and Gemini’s packworld.com are not in this group snapshot. Add them with a private group or source= if mandatory - the public pack is the industrial default, not every URL on the internet.

This is vertical manufacturing news, not healthcare or finance packs (healthcareTradePublications, top25finance).

How to monitor manufacturing and industrial automation news

Scope manufacturing trade publications first, then keywords or companies. Without a publisher gate, live manufacturing OR automation search can surface azonano.com explainers or jobs.magna.com recruiting pages - real pages elsewhere, not industrial trade publications desks. Lock the beat with sourceGroup=industrialTradePublications, then narrow with q (CNC, tariffs, recalls) or entities.

Stack industrial OEMs and automation vendors (resolved IDs)

Combine companyId or companySymbol with the group for OEM / vendor desks:

Company	Prefer	perigon companyId	Symbols to prefer
Rockwell Automation, Inc.	Controls / factory software OEM	0e4fcdf843bf44c69653340aff7729ee	ROK (NYSE)
Caterpillar Inc.	Heavy equipment / plant ops	a6aa46b5af9a45d590694b65741328fc	CAT (NYSE)
Siemens Aktiengesellschaft	Industrial / automation conglomerate	a4aa185497164ee4a72ad9bb8ae2ffe2	SIE.DE (XETRA) or SIEGY (OTC)

Name collisions to skip: Haas / Inductive / Tungsten “Automation” rows; Siemens Energy, Mobility, Healthineers (Healthineers is med-tech, not this pack); credit-union hits under “Caterpillar.” Prefer the parent industrial firm + symbol above.

Pattern: Articles with sourceGroup=industrialTradePublications and companySymbol=ROK (or Rockwell’s companyId) - trade allowlist + vendor, not open web. Company News pillar owns the full entity cookbook.

Example coverage snapshot (minimal, in-group)

Live pull: sourceGroup=industrialTradePublications + companySymbol=ROK - short overviews only (domain + summary; no article URLs):

manufacturing.net - Rockwell threat-detection managed services for industrial customers.

automationworld.com - Rockwell Connected Enterprise / shop-floor connectivity themes.

That is the shape of filter manufacturing news by source after you stop trusting an AI top list.

Use the same sourceGroup on the Stories API when one plant closure, strike, or automation rollout is reprinted across many trade pubs - you track the narrative cluster once instead of every wire copy (see the Stories clustering guide and Stories docs). For a short briefing of that filtered set, pass results into Search Summarizer. Add local / geography filters when the desk cares about a plant city or region, and historical date windows when you need archive depth - keep those recipes in their own guides rather than repeating them here.

Filter manufacturing news by source, company, topic, category, location, and date

Goal	Mechanism	Notes for industrial desks
Publisher allowlist	sourceGroup=industrialTradePublications	Full picture for this vertical
One-off domain	source / excludeSource	Titles AI named that are missing from the pack
Who is mentioned	companyId / companySymbol (ROK, CAT, Siemens AG)	Inside the group
What it is about	topic, category, taxonomy	Taxonomy pillar owns Google paths
Where the outlet sits	Local / source-location	Plant towns, regional construction
When	from / to / addDateFrom	Digests and incremental monitors

When an AI list is a brainstorm vs when you need Perigon’s pack

Situation	Prefer
Ideation slide (“names we recognize”)	AI shortlist - then verify
Production manufacturing news feeds and alerts	industrialTradePublications (725)
Must-have domain absent from the 44	Private group or source=
Publisher metadata	Sources API + group name
Another industry SERP	Healthcare or finance vertical posts

Key takeaways

Do not trust AI top-8 lists for industrial trade publications - models agree on little and miss most of the floor.

industrialTradePublications (725) is the fuller manufacturing trade publications picture: 44 domains across automation, plant engineering, machinery, supply chain, and more.

Filter manufacturing news by source with that sourceGroup; stack OEMs (ROK, CAT, Siemens AG) so job boards and random web hits stay out.

Use LLM lists as research only; use Perigon’s group as the operational allowlist. Keep third-party copy as short overviews - not republished articles.

Get started: Sandbox · Sources and source groups · API reference · API pricing