Google News Date-Window Export
Pricing
$1.00 / 1,000 news metadata rows
Google News Date-Window Export
Export Google News RSS metadata inside an exact UTC date window with bounded output and explicit exclusion receipts.
Pricing
$1.00 / 1,000 news metadata rows
Rating
0.0
(0)
Developer
Roman V
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
2 days ago
Last modified
Categories
Share
Export Google News RSS metadata inside an exact UTC date interval. This Actor is designed for small, auditable exports where date boundaries and predictable row counts matter more than article-body extraction.
What it does
- Sends one request to the public Google News RSS search endpoint.
- Applies an inclusive start and exclusive end after parsing every publication timestamp.
- Writes no more than 100 rows to the default dataset.
- Records outside-window, duplicate, malformed, ambiguous-timezone, output-cap, and billing-limit exclusions in
OUTPUT. - Returns the Google News link and source metadata without resolving redirects or opening publisher pages.
The source is a bounded feed with an unknown total. A successful run means every item in that response was evaluated. It does not mean every matching Google News item was available in the feed.
Input
The quickest useful run is an empty object:
{}
That searches for artificial intelligence, uses the previous seven complete UTC days, and returns at most 5 rows.
For an exact interval:
{"query": "artificial intelligence","startDate": "2026-09-01","endDate": "2026-09-07","maxItems": 5,"hl": "en-US","gl": "US","ceid": "US:en"}
startDate is inclusive at UTC midnight. endDate is exclusive at UTC midnight. Supply both dates or omit both. An explicit interval can span at most 31 days. Empty, malformed, partial, or reversed dates fail before any source request.
Dataset rows
Each delivered row contains:
titlepublishedAtnormalized to UTCgoogleNewsUrlfrom the feedsourceNameand a validsourceUrlwhen suppliedguidquery- deterministic
recordId
The Actor fetches no linked article, so it does not return article bodies or a resolved publisher URL.
Run receipt
Open the OUTPUT record to inspect:
- the resolved query and UTC interval;
- source request, retry, proxy, and linked-fetch counts;
- compressed and decoded response sizes;
- source, eligible, written, charged, and billing-excluded row counts;
- whether dataset delivery is confirmed, not attempted, or unknown after an ambiguous write;
- exclusion and failure receipts;
- the effective pricing mode for the run.
Statuses distinguish clean completion, genuine empty output, source item faults, output capping, billing capping, invalid input, source failure, pricing mismatch, and output failure. A run cannot stay COMPLETE when a spending limit prevents an eligible row from reaching the dataset.
Pricing
The configured Store price is $0.001 for each row written to the default dataset, using Apify's automatic apify-default-dataset-item event. There is no separate start event, custom result event, or platform-usage surcharge. Exclusions and receipts are not dataset items and are not charged as results.
Platform usage and event charges are separate concepts. Check the run receipt and Console cost details for the effective pricing on a particular run.
Safety and operational limits
- One source request, zero retries, zero redirects, and zero proxies. Environment proxy discovery is disabled.
- 20-second source timeout.
- 2,000,000-byte compressed response cap.
- 2,000,000-byte aggregate decoded response cap for identity, gzip, deflate, and Brotli.
- The full compressed stream is validated. Bounded concatenated gzip members are supported; corrupt, truncated, or unexpected trailing data is rejected.
- 1,000 source-item parse cap and 100 result-row cap.
- UTF-8 XML only. DTDs and entity declarations are rejected.
- Unknown publication timezones are excluded rather than guessed.
Before transport, the Actor stores a request-scoped run boundary. A completed run can restore its saved result without another source request or dataset push. An incomplete or ambiguous run fails closed on resurrection instead of making a second chargeable push. Confirmed write and charge counts survive later bookkeeping failures; genuinely ambiguous writes report unknown delivery and charge counts instead of asserting zero.