GlobeNewswire Press Releases Scraper

Fetches company press releases from GlobeNewswire's public RSS feeds -- either the latest across all of GlobeNewswire, or narrowed by one or more keyword/company/ticker search terms, each with its own result set.

What you get

One SEARCH_SUMMARY row per query plus one PRESS_RELEASE row per release, most-recent-first:

• releaseTitle, releaseSummary, releaseUrl
• releaseContent -- the complete press release body, fetched from the release's own detail page (on by default, one extra request per release; see "Full body" below)
• releaseCompany -- the issuing organization (upstream's dc:contributor)
• releasePublisher, releasePublishedAt, releaseModifiedAt
• releaseSubjects / releaseKeywords -- upstream's own topic tags
• releaseId, releaseLanguage

Query modes

Leave keywords empty to fetch the latest 20 press releases across all of GlobeNewswire. Add one or more keywords (company name, ticker, industry term) to instead fetch the latest 20 matching each one -- each keyword gets its own SEARCH_SUMMARY row. A keyword with no matches returns a genuinely empty result (verified during recon: 0 overlap with the "latest" feed for a nonsense keyword), not a silent fallback to the unfiltered list.

The feed window: 20 items, no pagination

Every GlobeNewswire RSS response documents itself as "Contains the last 20 releases" and recon found no working page/offset parameter. This actor does not offer one because it could not honestly serve it -- maxItemsPerQuery only caps below that 20-item ceiling, it cannot raise it. Run this actor on a schedule and de-duplicate downstream on releaseId if you want an accumulating history.

No WAF, no auth

Both the RSS feed and the news-release/*.html detail page answered clean on every TLS profile tested (chrome124, firefox133, safari17_0, chrome99_android), cold, no warmup. robots.txt's User-agent: * group disallows /newsroom/rss/, /search, /api/ and several other paths, but not /RssFeed/ (a distinct, undocumented path this actor uses) and explicitly Allow: /news-release/. See CRAWLING_METHOD.md for the full robots.txt capture and the policy reasoning.

Full body: fetched from the detail page, not from RSS or JSON-LD

The RSS <description> is only a short summary, and (checked this session) the detail page's own NewsArticle JSON-LD also only repeats that same summary -- neither carries the full release text. The complete body DOES exist on the detail page itself, in a plain HTML container (div.main-body-container.article-body), found by grepping a live page for body-like class names rather than assuming JSON-LD was the only structured option. Verified against 3 different releases (2,429 / 2,809 / 5,325 characters, genuinely complete start-to-boilerplate-contact-info). On by default (includeFullBody) -- turning it off saves one request per release if only the summary/metadata is needed.

Known limits

• No fetch of each release's detail page for the fuller NewsArticle JSON-LD (author org URL, dateline location) -- the body-text fetch above already visits that page, so this would be free to add later, just not built this session.
• On rare non-standard release templates, the body container may not be found -- handled explicitly with a releaseContentFetchError field on that row rather than a silent null (verified: 0 misses across every sample checked during recon, but the field exists so a future miss is visible, not invisible).