DEV Community: Daniel Meshulam

Google's News API has been gone since 2016, and people still search for it

Daniel Meshulam — Thu, 30 Jul 2026 18:44:36 +0000

Search for "google news api" and a striking share of the results are people
looking for something that no longer exists. Google deprecated the News Search
API in May 2011 as part of a wider AJAX Search API cull, kept it limping until
the final shutdown in February 2016, and never shipped a replacement. A decade
later the searches are still there.

What almost nobody mentions is that Google News still exposes a perfectly good
public endpoint. It is just an RSS feed rather than a JSON API, it needs no key,
and it has quietly outlived the API that was supposed to be the real product.

The endpoint

https://news.google.com/rss/search?q=<query>&hl=en-US&gl=US&ceid=US:en

That is the whole thing. Swap hl, gl and ceid for a different language and
country and you get that edition instead. There is no key, no quota page, and no
sign-up.

The catches are real but small:

It is RSS, so you get XML. Title, link, publication date, source name and a short description. No article body, and no way to ask for one.
The links are Google redirects, not publisher URLs. You have to follow them if you want the destination.
The publisher name lives in a nested <source> element, not where a normal feed parser looks for it.
Roughly 100 items per query. Deeper history is not available through it.

None of that is a reason to go and pay for a news API. It is a reason to write
about forty lines once.

Two sources are better than one

Bing News publishes its own RSS in the same shape at a different URL. Running
both and merging costs one extra request and meaningfully changes what you see,
because the two indexes disagree about what is worth surfacing.

Here is a real run over both:

16 articles
sources: {'google:semiconductor export controls': 8,
          'bing:semiconductor export controls': 8}

2026-07-09  Just Security          It Takes More Than Two to Tango: Creating...
2026-07-20  Reuters                China considers tighter export controls on...
2026-03-24  CSIS                   China's Localization Drive in Semiconductors...
2026-07-28  EU Today               China's Domestic DUV Push Puts ASML's Export...
2026-06-24  Purdue University      Intellectual Property Protection and Export...
2025-11-20  Cfr.org                Protecting the Foundation: Strengthening...
2026-07-19  The Motley Fool        Semiconductor Trade Statistics: U.S. Imports...

Every row carries title, url, publisher, publishedAt, summary,
source, image and guid.

One thing worth knowing if you parse Bing's feed yourself. It carries the
publisher in <News:Source>, and declares that prefix as

xmlns:News="https://www.bing.com/news/search?q=<your query>&format=RSS"

The namespace URI is the request URL, so it changes on every query and no fixed
namespace constant will ever match it. Match on the local element name instead.
I found this the way you would expect: publisher was null on exactly the Bing
half of a two-source run while the value was sitting in the feed the whole time.

The code

import json
import os
import urllib.request

ACTOR = "glitchbound~news-scraper"
API = "https://api.apify.com/v2"


def headlines(query, per_source=10):
    payload = {
        "searchQueries": [query],
        "maxArticlesPerSource": per_source,
        "language": "en",
        "includeBingNews": True,
        "dedupeHeadlines": True,
    }
    url = (f"{API}/acts/{ACTOR}/run-sync-get-dataset-items"
           f"?token={os.environ['APIFY_TOKEN']}&maxTotalChargeUsd=0.50")
    req = urllib.request.Request(
        url, data=json.dumps(payload).encode(), method="POST",
        headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=300) as r:
        rows = json.load(r)
    # A feed that fails comes back as a row with an `error` field rather than
    # failing the run, and those are not charged.
    return [r for r in rows if not r.get("error")]


for a in headlines("semiconductor export controls", per_source=5):
    # Fields can be absent on any given row, so read them defensively rather
    # than subscripting. Feeds are not schemas.
    when = (a.get("publishedAt") or "")[:10] or "no date"
    who = (a.get("publisher") or "unknown")[:28]
    print(f'{when:10}  {who:28} {(a.get("title") or "")[:60]}')

That runs News Scraper on
Apify, which is the same forty lines plus the parts that are
tedious rather than hard: both feeds, the nested publisher element, the date
normalisation, and deduplication.

If you would rather own the code, the endpoint above is public and this post has
told you everything you need.

Deduplication is most of the value

One wire story appears on dozens of syndicating domains, and Google and Bing will
both hand you several copies. A hundred raw results is frequently thirty stories.

Dedupe on the URL first, then on a normalised headline, because the same Reuters
piece appears under slightly different titles across outlets. Doing it on
headline alone merges genuinely different stories that share a phrasing; doing it
on URL alone leaves most of the duplication in place.

Where this does and does not fit

Fits: brand and competitor monitoring, tracking a topic across outlets,
building a corpus of headlines, seeing which publishers cover a beat, feeding a
summarisation pipeline.

Does not fit: anything needing article text, anything needing more than a few
months of history, or academic archival work. For those you want a licensed
provider, and the honest answer is that no free endpoint replaces one.

What it costs

If you write it yourself, nothing beyond your own hosting.

Through the Actor it is $1.50 per 1,000 articles on the free tier, so a daily run
pulling 50 articles is about seven cents a month, plus a $0.02 Actor-start event
per run. Duplicates that get dropped are not charged, and neither are feeds that
fail.

The wider point

An enormous amount of "you need an API for this" is habit. Google News, Apple's
app charts, the SEC, the World Bank, the ECB and Open Food Facts all publish
usable public endpoints that need no key and get very little attention, largely
because there is no vendor with an incentive to tell you about them.

Worth checking before you pay for access to public data.

Code

Runnable examples are here:
github.com/danielhagever/apify-data-actors

WHOIS is gone, RDAP replaced it, and a 404 does not mean what you think

Daniel Meshulam — Thu, 30 Jul 2026 18:02:58 +0000

If you last touched domain lookups a few years ago, the thing you remember is
WHOIS: a plaintext protocol on port 43 that returned an unparseable wall of text
in a different shape from every registry.

It is effectively gone. RDAP replaced it, it is RFC 9083, it returns JSON, and
every gTLD registry is required to run one. This is one of the rare cases where
the standards process produced something strictly better and nobody noticed.

Here is what a lookup looks like now, what you can actually get out of it after
GDPR, and the one trap that had my own tool confidently reporting registered
domains as free to buy.

What RDAP gives you, and what it does not

Post-GDPR, RDAP returns no registrant personal data for virtually every TLD. If
you are looking for who owns a domain, stop: that information is not there and
no legitimate source has it.

What is there is the operational picture, and that turns out to be the more
useful half:

registrar, registration date, expiry date, status codes, DNSSEC
whether the name is locked against transfer

Combine that with a DNS lookup and you get the thing people actually want, which
is what a company runs on:

domain        registrar                expires       age mail       dns         dmarc
stripe.com    SafeNames Ltd.           2027-09-11   30.9 google     aws-route53 reject
linear.app    CloudFlare, Inc.         2030-05-09    8.2 google     cloudflare  reject
vercel.com    Amazon Registrar, Inc.   2029-10-04   26.8 google     vercel      quarantine
github.io     -                        -               - -          aws-route53 -
angel.co      -                        -               - google     cloudflare  reject
notion.so     -                        -               - -          cloudflare  quarantine

That is a real run. Mail provider and DNS provider come from MX and NS records,
DMARC policy from a TXT lookup at _dmarc.<domain>. For sales qualification,
security auditing or competitive research, those three columns are worth more
than any registrant field ever was.

Note the bottom three rows have DNS but no registrar and no expiry. Hold that
thought.

The code

import json
import os
import urllib.request

ACTOR = "glitchbound~whois-domain-lookup"
API = "https://api.apify.com/v2"


def profile(domains):
    payload = {
        "domains": domains,
        "includeDns": True,
        "recordTypes": ["A", "MX", "NS", "TXT"],
        "includeEmailSecurity": True,
    }
    url = (f"{API}/acts/{ACTOR}/run-sync-get-dataset-items"
           f"?token={os.environ['APIFY_TOKEN']}&maxTotalChargeUsd=0.50")
    req = urllib.request.Request(
        url, data=json.dumps(payload).encode(), method="POST",
        headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=300) as r:
        rows = json.load(r)
    # A domain that could not be looked up comes back as a row with an `error`
    # field rather than failing the run, and those are not charged.
    return [r for r in rows if not r.get("error")]


for r in profile(["stripe.com", "linear.app", "vercel.com"]):
    print(f'{r["domain"]:14} {r.get("mailProvider") or "-":10} '
          f'{r.get("dnsProvider") or "-":12} dmarc={r.get("dmarcPolicy") or "-"}')

That runs an Apify Actor I maintain,
WHOIS Domain Lookup, because the
tedious parts are the RDAP bootstrap, the vcard unpacking and the provider
fingerprinting rather than the HTTP call. If you would rather do it yourself,
https://rdap.org/domain/<name> is the whole API and it needs no key.

The trap: a 404 is ambiguous

rdap.org is a router. It reads IANA's bootstrap registry, finds the RDAP
server for your TLD, and redirects. A 404 back from it looks like it means one
thing: no registry holds this name, therefore the domain is available.

That is what my tool assumed. It was wrong, and the failure is ugly:

rdap.org/domain/github.io    404
rdap.org/domain/notion.so    404
rdap.org/domain/segment.io   404
rdap.org/domain/angel.co     404

All four are registered. All four returned 404.

The reason is that IANA's bootstrap does not cover every TLD. It lists RDAP
services for around 1,200 of them, and some of the most common startup TLDs are
not in there:

.io   .co   .de   .me   .so   .gg   .sh

For those, rdap.org has nowhere to send the query, so it 404s for every name
under them, registered or not. My Actor turned that into isAvailable: true and
would have told you github.io was free to register.

On a tool whose headline feature is availability checking, that is the worst
possible way to be wrong: confident, plausible, and acted upon. Nobody
double-checks a clear answer.

The fix, in two parts

Ask whether there is a registry at all. Fetch
https://data.iana.org/rdap/dns.json once, build the set of TLDs that have an
RDAP service, and only treat a 404 as "available" when the TLD is in it.

import json, urllib.request

def rdap_tlds():
    d = json.load(urllib.request.urlopen("https://data.iana.org/rdap/dns.json"))
    return {t.lower().lstrip(".") for entry in d["services"] for t in entry[0]}

Let DNS settle the rest. A name with NS records has been delegated by the
registry, and a registry does not delegate a name nobody registered. So for the
TLDs with no RDAP, NS records prove registration even though RDAP cannot.

The reverse does not hold, and this is the part worth being careful about: a
registered domain can have no NS at all. So "no NS and no RDAP" is not
"available", it is unknown, and it should be returned as null with an
explanation rather than as a guess. A null is a fact the caller can handle. A
plausible wrong answer is not.

Why this generalises

The bug was not really about RDAP. It was about reading an absence as a
definite answer.

404 means "I have nothing for you". Whether that is because the thing does not
exist, or because you asked somewhere that was never going to know, is not in
the response. Any time you convert a missing result into a positive claim, check
that you actually asked something capable of answering.

I have now hit the same shape four times in a month in different tools: an API
silently ignoring a filter it does not support, a page parser taking the first
number in a plausible range, this, and crt.sh, which answers 404 when it is
refusing traffic and reports "nothing found" as an empty list with a 200. All of
them produced output that looked completely normal.

What it costs

Charged per domain returned, at $2.00 per 1,000 on the free tier, so a hundred
domains is 20 cents plus a $0.02 Actor-start event. Domains removed by the
built-in filters, like onlyRegistered or expiringWithinDays, are not charged,
and neither are lookups that fail.

Notes

Some ccTLDs run thin RDAP servers that return fewer fields. You get whatever the registry publishes rather than an error.
DNS answers are returned sorted. Resolvers round-robin, and unsorted output makes a scheduled run look like it changed every time when nothing did.
Availability comes from the registry itself, not a reseller API, so there is no incentive for anyone to tell you a name is taken when it is not.

Code

Runnable examples are here:
github.com/danielhagever/apify-data-actors

Every example input in that repo is generated from the Actor's own input schema,
so it is valid by construction rather than by my memory of the field names.

The App Store top charts are a public API, and nobody archives them

Daniel Meshulam — Thu, 30 Jul 2026 16:19:14 +0000

Apple's top charts are one of the few genuinely useful public rankings left.
They are free, they need no key, and they update daily.

They also have one property that makes them frustrating: there is no history.
The feed shows you today. Yesterday is gone. If you want to know whether an app
climbed or slid, or which category a publisher quietly took over last month, that
data does not exist anywhere unless somebody was writing it down.

Nobody is writing it down, which means the archive is worth more than the feed.

This post covers both halves: reading the charts today, and the small amount of
work it takes to have a year of history in a year's time.

The feed

Apple's RSS feeds sit at a predictable URL per country, chart type and category.
No key, no login, and no bot wall. That is unusual enough in 2026 to be worth
saying out loud.

What is awkward is the shape. Each entry buries the app id under
id.attributes["im:id"], the price under im:price.attributes, the developer
under im:artist.label, and the icon in an array where you want the last
element. Parsing it correctly is 30 lines of nested .get() calls that you write
once and never enjoy.

I put that in an Apify Actor,
App Store Top Charts Scraper,
so I could stop rewriting it. One HTTP call runs it and returns flat rows.

import json
import os
import urllib.request

ACTOR = "glitchbound~app-charts-scraper"
API = "https://api.apify.com/v2"


def top_charts(countries, charts=("top-free",), limit=50):
    payload = {
        "countries": list(countries),
        "charts": list(charts),
        "categories": ["all"],
        "limit": limit,
    }
    url = (f"{API}/acts/{ACTOR}/run-sync-get-dataset-items"
           f"?token={os.environ['APIFY_TOKEN']}&maxTotalChargeUsd=0.50")
    req = urllib.request.Request(
        url, data=json.dumps(payload).encode(), method="POST",
        headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=300) as r:
        rows = json.load(r)
    # A country or chart that fails comes back as a row with an `error` field
    # rather than failing the run, and those are not charged. Split them out or a
    # run that fetched nothing still looks successful.
    return [r for r in rows if not r.get("error")]


rows = top_charts(["us", "gb", "de"], charts=["top-free"], limit=20)
for r in sorted(rows, key=lambda r: (r["country"], r["rank"])):
    print(f'{r["country"]}  #{r["rank"]:<3} {r["title"][:42]:42} {r["developer"][:24]}')

Real output, from an actual run, top of the German chart:

DE  #1   Claude by Anthropic                        Anthropic PBC
DE  #2   ChatGPT                                    OpenAI OpCo, LLC
DE  #3   Nect Wallet                                Nect
DE  #4   Google Gemini                              Google
DE  #5   EasyPark parken - Park App                 Easy Park AS
DE  #6   AusweisApp Bund                            Governikus GmbH & Co. KG
DE  #7   Mein dm                                    dm-drogerie markt GmbH +
DE  #8   Post & DHL                                 Deutsche Post AG

That German top ten is itself the argument for archiving. Four of those eight are
government or logistics apps that nobody would predict from the US chart, and the
top two are AI assistants that were not in this chart at all two years ago. You
cannot see either of those facts in a single pull.

Every row also carries appId, bundleId, price, currency, isFree,
genre, releaseDate, icon and url, so a chart pull doubles as an app
metadata pull.

The part that is actually valuable

One pull tells you the ranking today, which you could have read off your phone.
The interesting queries all need two pulls separated by time:

Which apps entered the top 20 this week
Which publisher gained the most chart slots this month
How long a given app has held its position
Whether a competitor's launch actually moved anything
Which categories are churning and which are frozen

None of that is answerable from the feed. All of it is answerable from a table
you append to daily.

So the whole trick is: run it on a schedule and never delete anything.

import datetime as dt

rows = top_charts(["us"], charts=["top-free", "top-paid"], limit=100)
stamp = dt.datetime.now(dt.timezone.utc).isoformat(timespec="seconds")
for r in rows:
    r["capturedAt"] = stamp          # the feed has no timestamp; add your own
# append to wherever you keep things: Postgres, SQLite, a CSV, a dataset

On Apify you get this without writing the storage layer: put the Actor on a
Schedule and every run appends to the same dataset, each with its own timestamp.
Three months later you have something nobody sells.

One detail that matters if you build this yourself: the feed carries no
timestamp of its own. If you do not stamp each capture at write time, a year
later you have a pile of rankings and no way to order them. Stamp it on the way
in, not on the way out.

What it costs

Charged per chart entry returned. A 100-app chart is 100 results, so at $3.00 per
1,000 on the free tier a daily 100-app capture for one country is about 30 cents
a month, plus a $0.02 Actor-start event per run. Countries and chart types
multiply that, so pick the markets you actually care about rather than sweeping
all of them.

Rows that come back as errors are not charged.

Caveats worth stating plainly

Apple only. Google Play publishes no equivalent public chart feed. Anything claiming a Play "top chart" API is scraping a rendered page, which breaks on redesign.
Charts are per country, per chart type, per category. An app can be absent from top-free while sitting high in top-grossing. "Not in the chart" is always relative to which chart you asked for.
Apple caps a feed at 200 entries. Beyond that the answer does not exist in the feed.
Rankings are Apple's, computed however Apple computes them. This reads them; it does not model them.

Code

Runnable examples, including this one, are here:
github.com/danielhagever/apify-data-actors

Every example input in that repo is generated from the Actor's own input schema,
so they are valid by construction rather than by my memory of the field names.

Find startups the day they raise, before the press release, with 30 lines of Python

Daniel Meshulam — Thu, 30 Jul 2026 16:16:48 +0000

Funding announcements are old news by the time you read them. There's usually a
gap of weeks between a company closing a round and telling anyone about it. In
that gap, the round is already a matter of public record.

That's because of Form D. When a US company sells securities in a private
placement, it has to file one with the SEC, generally within 15 days of the first
sale. It's a legal requirement, it's public the moment it's accepted, and almost
nobody reads it.

So the question is not whether you can see funding rounds early. It's how to
filter thousands of Form Ds a month down to the ones you care about.

This post is the working version of that, end to end: ~30 lines of Python, real
output, and the two traps that cost me a couple of hours.

Why you can't just list Form Ds

The naive approach is "give me every Form D from the last 90 days." That's
thousands of filings: real estate syndicates, hedge funds, family offices, a
long tail of LLCs. Most of it is not what anyone means by "a startup raised."

You also can't filter by company name, because you don't know the company
names yet. That's the entire point of the exercise.

What you want is a full-text search over the body of the filings, scoped to
Form D and to a recent window. EDGAR supports exactly that, over every filing
since 2001.

The code

I'm using an Apify Actor I built for EDGAR,
SEC EDGAR Scraper, because
it handles the parts of EDGAR that are tedious: CIK resolution, the fair-access
rate limit, XBRL, and the date-range bug I'll get to below. One HTTP call runs it
and returns rows.

import datetime as dt
import json
import os
import urllib.request

ACTOR = "glitchbound~sec-filings-scraper"
API = "https://api.apify.com/v2"


def form_d_by_sector(sector: str, days: int = 90) -> list[dict]:
    since = (dt.date.today() - dt.timedelta(days=days)).isoformat()
    payload = {
        # Quote the phrase or EDGAR matches the words separately.
        "searchQuery": f'"{sector}"',
        "formTypes": ["D"],
        "filedSince": since,
        "maxSearchResults": 50,
    }
    url = (f"{API}/acts/{ACTOR}/run-sync-get-dataset-items"
           f"?token={os.environ['APIFY_TOKEN']}&maxTotalChargeUsd=0.50")
    req = urllib.request.Request(
        url, data=json.dumps(payload).encode(), method="POST",
        headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=300) as r:
        rows = json.load(r)

    # A target the Actor couldn't resolve comes back as a row with an `error`
    # field instead of failing the whole run, and those aren't charged. Count
    # them separately or a run that fetched nothing still looks successful.
    return [r for r in rows if not r.get("error")]


for f in sorted(form_d_by_sector("artificial intelligence"),
                key=lambda r: r["filingDate"], reverse=True):
    print(f"{f['filingDate']}  {f['companyName']:55} {f.get('state') or '--'}")
    print(f"            {f['filingUrl']}")

Set APIFY_TOKEN from
console.apify.com/settings/integrations
and run it.

Real output

This is an actual run, not a mockup:

2026-07-06  Flo Artificial Intelligence, Inc.  (CIK 0001798621)      CA
            .../data/1798621/000179862126000003/primary_doc.xml
2026-06-29  Artificial Intelligence Financial Services Market Inc.   DE
            .../data/2142624/000214262426000001/primary_doc.xml
2026-06-29  Artificial Intelligence Financial Services Market Inc.   DE
            .../data/2142624/000214262426000002/primary_doc.xml
2026-06-18  Panorama Artificial Intelligence Corp.                   WA
            .../data/2001638/000200163826000001/primary_doc.xml
2026-05-26  Artificial Intelligence Progress Research, LP            --
            .../data/2133240/000213324026000002/primary_doc.xml
2026-05-15  Allied Innovation Artificial Intelligence Fund, LLC      NY
            .../data/2021379/000202137926000001/primary_doc.xml
2026-05-05  Artificial Intelligence Progress Research, LP            --
            .../data/2133240/000213324026000001/primary_doc.xml

(URLs truncated for width; the real ones are absolute sec.gov links.)

Seven filings, each linking straight to the primary document on sec.gov. Every one
is a real entity that filed a real Form D in that window.

Note that the same company can appear twice, with two separate accession numbers
on 2026-06-29. Those are genuinely two filings, not a duplicate row: an amended Form
D gets its own accession. Dedupe on companyName only if you actually want to.

You'll notice something honest about this list: it is heavy on entities with
"Artificial Intelligence" in the company name, plus a couple of funds. That's
what a full-text phrase search gives you. It matches the text of the filing, and
Form D is a short form without a business description. It's a strong signal,
not a magic sector classifier. More on that below.

Trap 1: EDGAR silently ignores a half-open date range

This one cost me real money before I caught it.

EDGAR's full-text endpoint takes startdt and enddt alongside
dateRange=custom. Send only startdt and it does not narrow anything, and it
does not tell you either. Measured against the live endpoint, same query, forms=D:

Parameters	Hits	Oldest result
`startdt` only	53	2015-07-28
no date params at all	53	2015-07-28
`startdt` + `enddt`	7	2026-05-05

startdt alone is byte-for-byte identical to sending no filter. If you're paying
per result, you're paying for eleven years of filings outside the window you
asked for, and the response looks perfectly normal.

If you're calling EDGAR directly: always send both bounds. Default the
missing one: 2001-01-01 is the floor for full-text search, and today for the
upper bound. (This is fixed in the Actor as of build 0.1.4; that's why the run
above returns 7 and not 53.)

Trap 2: "recent" isn't the sort you want for anything else

For funding discovery, newest-first is right. For almost every other EDGAR
question it isn't. If you're looking for the filing that matters on a topic,
recency is noise. Worth knowing before you build the wrong dashboard.

What this costs

The Actor charges per result: $3.00 per 1,000 on the free tier, so seven filings
is 2.1 cents, plus a one-time $0.02 Actor-start event, so about 4 cents for
the run. Paid Apify tiers pay less per result, down to half that on Gold.

The maxTotalChargeUsd=0.50 in the code above is a hard
ceiling the platform enforces. The run stops cleanly at the limit rather than
being killed mid-write, so you can't accidentally spend more than you meant to.

Rows that come back as errors, such as a ticker that doesn't resolve or a query
EDGAR rejects, aren't charged.

Going further

A few directions that work well from here:

Watch a sector on a schedule. Run it daily with days=2 and diff against
what you've already seen. New Form Ds show up the day they're accepted.

Pivot to the company. Once a name appears, feed its CIK back in with
includeFinancials: true to get XBRL figures: revenue, net income, total assets,
straight from what the company tagged, not scraped off a rendered page. A full
20-year history is one request, because it comes from companyfacts.

Search for other things entirely. formTypes: ["8-K"] with a phrase like
"material weakness" or "going concern" finds every company that disclosed it.
formTypes: ["4"] is insider trades. formTypes: ["13F-HR"] is what the big
funds hold.

Caveats worth stating plainly

Form D is a filing, not a validated funding announcement. It tells you securities were sold under a Reg D exemption. It does not confirm a venture-style round, and the amounts on the form are frequently the maximum offering rather than what closed.
Full-text phrase search matches text, not sectors. As the output shows, it finds companies whose filings contain your phrase, which correlates with the sector but isn't the same thing. For real classification you'd want to pull the filing and read it.
This is public disclosure, and that's the whole appeal. No login, no key, no scraping of rendered pages. The SEC asks callers to identify themselves and stay under 10 requests/second, which the Actor does.
Not investment advice, obviously.

Code

Full runnable scripts, including this one and a few others, are here:
github.com/danielhagever/apify-data-actors

Every example input in that repo is generated from the Actor's own input schema,
so they're valid by construction rather than by my memory of the field names.
That's a habit I picked up after the reviewedAt-vs-date mistake in a
different script cost me an afternoon of blank output.

If you find a case where EDGAR behaves differently than described here, I'd
genuinely like to know. That date-range trap only surfaced because I ran the
example instead of just writing it.