DEV Community: Ben Barazandeh

Collecting App Store Reviews by Country and Version With Apple's Public Feed

Ben Barazandeh — Fri, 30 Oct 2026 14:12:14 +0000

Disclosure: I'm Ben, and I built the Apify Actor mentioned later in this post. I charge per result for it. Everything in the tutorial part works with free tools too.

A star average tells you almost nothing. "4.6 stars" hides the fact that version 7.144.0 broke streak freezes for half your users in the UK. What product teams actually want is reviews by version and by country, for their own app and for competitors.

For your own app, App Store Connect has the reviews and lets you reply. For any other app, there's no official reviews API, but Apple does publish a public customer-reviews feed per storefront, and the iTunes Search/Lookup API covers the app metadata.

How the feed works

https://itunes.apple.com/{country}/rss/customerreviews/page={n}/id={appId}/sortby={mostrecent|mosthelpful}/json

country is a storefront code (us, gb, de, jp, br…). Every storefront has its own reviews.
Each page has up to 50 reviews, and you get at most 10 pages per sort order. That's 500 for mostrecent and 500 for mosthelpful.
Each entry has the rating, title, text, author, app version and date.

The app ID is the number after id in the App Store URL (389801252 for Instagram). If you only have a name, the iTunes Search API turns it into an ID, and Lookup gives you the average rating, rating count and current version.

Step 1: A collector you can run today

This pulls both sort orders for one storefront and dedupes on review ID. It ran as-is on 25 Oct 2026:

import requests, time

def reviews(app_id, country="us"):
    seen = {}
    for sort in ("mostrecent", "mosthelpful"):
        for page in range(1, 11):  # Apple serves at most 10 pages of 50 per sort order
            url = (f"https://itunes.apple.com/{country}/rss/customerreviews/"
                   f"page={page}/id={app_id}/sortby={sort}/json")
            entries = requests.get(url, params={"_": int(time.time())}, timeout=30) \
                              .json().get("feed", {}).get("entry", [])
            if isinstance(entries, dict):  # defensive: normalise a lone object to a list
                entries = [entries]
            for e in entries:
                if "im:rating" not in e:
                    continue  # skip anything that isn't a review
                seen[e["id"]["label"]] = {
                    "rating": int(e["im:rating"]["label"]), "version": e["im:version"]["label"],
                    "title": e["title"]["label"], "date": e["updated"]["label"]}
            if not entries:
                break
            time.sleep(0.5)
    return list(seen.values())

rows = reviews(389801252, "gb")   # Instagram, UK storefront
print(len(rows), "unique reviews")
print(sum(r["rating"] <= 2 for r in rows), "are 1-2 stars")

I ran it twice, a few minutes apart. The first run printed 749 unique reviews / 492 are 1-2 stars. The second printed:

996 unique reviews
611 are 1-2 stars

Same app, same storefront, same code. The difference is the feed's habit of returning an empty page before the real end: my loop treats an empty page as "done", so the first run stopped early on at least one sort order. That's the most important pitfall in this whole post, and the fix is to retry empty pages (with a fresh cache-buster) before giving up.

Also notice the skew: the newest and "most helpful" reviews lean negative (611 of 996 here). That describes this sample, not every review ever written.

Step 2: The pitfalls

The cap is per sort order and per country. To see more, add storefronts. A US-only pull misses most of the feedback for an app that's big in Germany, Japan or Brazil.
History needs polling. You only ever see roughly the newest 500. To build a full history, run on a schedule and keep what you've already stored.
Empty pages that aren't the end. As above. Retry an empty page a couple of times with a new cache-busting parameter before you treat it as the last page.
Structure. Every value is wrapped in {"label": ...}, and dates come with a UTC offset (e.g. -07:00). Normalise to UTC before you compare countries.
Version is the useful field. Group 1★ reviews by im:version and release-related spikes jump out.

Step 3: Or use the packaged version

I packaged this as an Apify Actor, App Store Reviews Scraper. It takes App Store URLs, numeric IDs or plain app names, any number of countries, and sort set to most recent, most helpful or both (deduplicated, up to about 1,000 unique per app per country).

{
  "apps": ["https://apps.apple.com/us/app/instagram/id389801252", "duolingo"],
  "countries": ["us", "gb"],
  "maxReviewsPerApp": 50
}

You can filter by min/max stars, "only reviews since" a date, and keywords in the title or text. Filtered-out reviews aren't charged. Optional app details go on every row: name, developer, bundle ID, genre, average rating, rating count, current version.

That input returned 200 reviews from 4 app/country combinations in about 22 seconds on 18 Oct 2026. Some rows:

App	Store	Rating	Review title	Version	Date
Instagram	GB	★★★★★	Like a digital scrap book	451.0.0	2026-10-17
Instagram	GB	★	Suspended exile	451.0.0	2026-10-16
Duolingo: Learn Languages	US	★	Annoying streak freezes	7.144.0	2026-10-17
Duolingo: Language & Chess	GB	★★★★★	So good	7.144.0	2026-10-17

Note the name difference: the same Duolingo app has a different title in the US and UK storefronts.

The workflow I'd use

Your app plus 3–5 competitors, in the 5–10 countries that matter to you.
maxRating: 2 for a complaints feed, or no filter for everything.
A weekly schedule with "only reviews since" set to last week.
Send the rows to a sheet, or to an LLM step that clusters complaints by version.

Limits, honestly

Apple's cap is the cap. About 500 per sort order per country, so around 1,000 per country at best. Anything older is only reachable if you started polling earlier.
No Google Play. There's no official public reviews API for other people's apps on Play.
Not affiliated with Apple.

What it costs

$0.0002 per review ($0.20 per 1,000). App lookups and filtered-out reviews are free, there's no start fee, and runs stop at your "maximum cost per run". The 200-review test above came to 4 cents. Some Store Actors are slightly cheaper per review. The script above is free.

Play fair

Reviews are public, but they're written by people. Don't republish them with names attached, and follow Apple's terms and privacy laws.

How do you analyse reviews today: by hand, with tags, or with an LLM? I'm curious what's actually worked for you, so tell me in the comments.

Finding Contact Emails on Company Websites Politely: robots.txt, mailto, JSON-LD and the Traps

Ben Barazandeh — Thu, 29 Oct 2026 14:03:03 +0000

Disclosure: I'm Ben, and I built the Apify Actor mentioned later in this post. I charge per result for it. Everything in the tutorial part works with free tools too.

You have a list of company domains (a CRM export, a lead list, a spreadsheet from an event) and you need a contact email, a phone number and maybe the company's Instagram or LinkedIn. The details are usually right there on the company's own site. Getting them reliably, and politely, takes more care than a regex over the homepage.

Step 1: A minimal, polite extractor

This is roughly the smallest version I'd be comfortable running against small-business sites. It checks robots.txt with its own User-Agent, reads the homepage, pulls mailto: and tel: links, and lists same-domain contact/about pages to visit next. It ran as-is on 25 Oct 2026:

import re, urllib.request, urllib.robotparser
from urllib.parse import urljoin, urlparse

UA = "MyContactBot/0.1 (+mailto:you@example.com)"

def fetch(url):
    req = urllib.request.Request(url, headers={"User-Agent": UA})
    with urllib.request.urlopen(req, timeout=15) as r:
        return r.geturl(), r.read().decode("utf-8", "ignore")

def contacts(site):
    rp = urllib.robotparser.RobotFileParser()
    try:  # fetch robots.txt with *your* UA; RobotFileParser.read() uses urllib's default
        rp.parse(fetch(urljoin(site, "/robots.txt"))[1].splitlines())
    except Exception:
        rp.parse([])  # no robots.txt (404) means allowed
    if not rp.can_fetch(UA, site):
        return {"site": site, "status": "blocked_by_robots_txt"}
    final, html = fetch(site)
    emails = set(re.findall(r'mailto:([^"\'?>\s]+)', html, re.I))
    phones = set(re.findall(r'tel:([+\d()\-. ]{7,})', html, re.I))
    host = urlparse(final).netloc
    contact_links = {urljoin(final, h) for h in re.findall(r'href="([^"]+)"', html)
                     if re.search(r"contact|about|impressum", h, re.I)
                     and urlparse(urljoin(final, h)).netloc == host}
    return {"site": final, "emails": sorted(emails), "phones": sorted(phones),
            "contactPages": sorted(contact_links)[:5]}

print(contacts("https://www.aloha-dental.com/"))

Output:

{'site': 'https://www.aloha-dental.com/', 'emails': [], 'phones': ['(512)707-7300'],
 'contactPages': ['https://www.aloha-dental.com/about-us/', 'https://www.aloha-dental.com/contact-us/']}

Two lessons from that one run.

First, the homepage had no email. The phone was there as a tel: link, but the address lives deeper in the site. My packaged tool (below) found riverside@aloha-dental.com on the same site after visiting 5 pages. You almost always need to follow the contact/about links.

Second, my first version wrongly reported this site as blocked by robots.txt. Python's RobotFileParser.read() fetches robots.txt with urllib's default User-Agent, the server answered 403, and the parser treats an access error as "disallow everything". Fetching robots.txt yourself with your real UA fixed it. If your crawler says "blocked" a lot, check that before blaming the sites.

Step 2: The traps you'll hit next

Emails aren't only in mailto:. Look in page text, and in schema.org JSON-LD ("email", "telephone", "address"), which a lot of small-business sites ship through their CMS or SEO plugin.
Obfuscation. Cloudflare's email protection replaces addresses with a data-cfemail hex string (a simple XOR you can decode). People also write name [at] domain [dot] com.
Junk addresses. Placeholder and tracking addresses (example.com, Sentry DSNs, wixpress) show up in page source. Filter them.
Dead domains. An email whose domain has no MX record won't receive mail. A DNS lookup is cheap and doesn't touch anyone's mailbox.
Phone false positives. Order numbers, dates and prices look like phone numbers in text. Trust tel: links and schema.org more than regexes.
No contact link at all. Fall back to trying /contact, /contact-us and /about.
Be slow. These are often tiny shared-hosting sites. One request per second per site, an identifiable User-Agent, and robots.txt Crawl-delay if they set one.

Step 3: Or use the packaged version

I packaged this into an Apify Actor, Website Contact Scraper. You paste domains, URLs or emails, and get one row per company:

Emails from mailto:, text, JSON-LD, Cloudflare-protected and "[at]/[dot]" forms. Each is tagged sameDomain, role (info@, sales@…) and domainAcceptsMail (the MX check).
Phones from tel: and schema.org. Numbers found only in text go into a separate phonesUncertain list.
13 social networks (LinkedIn, Facebook, Instagram, X, YouTube, TikTok, Pinterest, GitHub, Threads, Telegram, WhatsApp, Discord, Yelp), plus contactPageUrls
Company name and postal address when the site publishes them in schema.org or OpenGraph

It crawls the homepage plus up to 19 contact/about/impressum/team pages on the same domain, honours robots.txt (including Crawl-delay), goes 1 request per second per site and identifies itself as ContactEnrichmentBot. It doesn't run JavaScript.

The real result for the site above (trimmed):

{
  "domain": "aloha-dental.com",
  "status": "ok",
  "companyName": "Aloha Dental",
  "primaryEmail": "riverside@aloha-dental.com",
  "phones": ["(512)707-7300"],
  "phonesUncertain": ["(512) 494-5655"],
  "address": "1614 E. Riverside DR., Austin, Texas, 78741, US",
  "contactPageUrls": ["https://www.aloha-dental.com/contact-us/"],
  "instagram": ["https://www.instagram.com/alohadentaltx"],
  "pagesCrawled": 5,
  "charged": true
}

Real fill rates

From live runs on 17 Oct 2026, measured over sites that were actually reached:

Test	Websites	Reached	Email	Phone	Instagram	LinkedIn	Contact page
Manchester restaurant/café sites	90	72	68%	62%	76%	11%	70%
Mixed: US trades/dentists, Paris cafés, 12 SaaS companies	55	49	55%	57%	69%	59%	89%

The sites that weren't reached were blocked by robots.txt (7 and 4 sites, never crawled), returned HTTP 403/404, had no DNS, or timed out.

Limits, honestly

No JavaScript rendering. Sites that only render contact details client-side return fewer results.
Some sites block data-centre IPs. You can set an Apify Proxy, which Apify bills separately.
Email isn't guaranteed. Between a third and almost half of the reached sites in the tests had no email at all (32% and 45%). Many small businesses only offer a contact form, which is why contactPageUrls is there.
The MX check isn't verification. It confirms the domain accepts mail, not that the mailbox exists. The tool never sends mail or probes mailboxes.

What it costs

$0.002 per website where at least one email, phone or social profile was found ($2 per 1,000). Websites that are unreachable, blocked by robots.txt or empty are free (charged: false). In the mixed test, 47 of the 55 sites were charged, which is 9.4 cents. With a $0.01 max-cost cap, it charged exactly 5 sites and stopped. The script above is free.

Play fair

Named employees' emails and phones are personal data under GDPR, UK GDPR and CCPA, and you're the data controller. Have a lawful basis, honour opt-outs, follow CAN-SPAM, CASL and PECR, and if you want to minimise personal data, keep only the role addresses (role: true). Please don't build spam lists with any of this.

What obfuscation trick have you run into that I haven't listed? Tell me in the comments and I'll add a decoder for it.

Domain Age, Email Provider and DMARC From a List of Domains: RDAP + DNS-over-HTTPS in Python

Ben Barazandeh — Wed, 28 Oct 2026 14:08:21 +0000

Disclosure: I'm Ben, and I built the Apify Actor mentioned later in this post. I charge per result for it. Everything in the tutorial part works with free tools too.

A list of domains says a lot more than it looks. From public data alone you can tell how old a domain is, when it expires, who hosts its DNS, whether the company is on Google Workspace or Microsoft 365, and whether it has a DMARC policy. That's useful for fraud checks ("this domain is 12 days old"), deliverability audits, and segmenting a lead list ("Microsoft 365 shops with no DMARC").

You don't need a WHOIS API subscription for most of it. You need two open protocols: RDAP and DNS.

RDAP in one paragraph

RDAP is the official, structured JSON successor to WHOIS, run by the same registries. IANA publishes a bootstrap file (data.iana.org/rdap/dns.json) that tells you which RDAP server handles each TLD. You look up the TLD, then call {server}/domain/{name}. A 404 means the registry has no record, so the domain is probably available.

Step 1: Registration dates + DNS in ~30 lines

This ran as-is on 25 Oct 2026. DNS goes through Cloudflare's public DNS-over-HTTPS JSON endpoint, so there's nothing to install beyond requests.

import requests

def rdap(domain):
    tld = domain.rsplit(".", 1)[-1]
    services = requests.get("https://data.iana.org/rdap/dns.json", timeout=30).json()["services"]
    base = next((urls[0] for tlds, urls in services if tld in tlds), None)
    if not base:
        return None  # this TLD has no RDAP server: fall back to port-43 WHOIS
    r = requests.get(f"{base.rstrip('/')}/domain/{domain}", timeout=30)
    if r.status_code == 404:
        return {"registered": False}
    ev = {e["eventAction"]: e["eventDate"] for e in r.json().get("events", [])}
    return {"registered": True, "created": ev.get("registration"), "expires": ev.get("expiration")}

def dns(name, rtype):
    r = requests.get("https://cloudflare-dns.com/dns-query", params={"name": name, "type": rtype},
                     headers={"accept": "application/dns-json"}, timeout=30).json()
    return [a["data"] for a in r.get("Answer", [])]

for d in ["stripe.com", "spiegel.de"]:
    print(d, rdap(d))
    print("  MX   ", dns(d, "MX")[:2])
    print("  DMARC", dns(f"_dmarc.{d}", "TXT"))

Output (trimmed):

stripe.com {'registered': True, 'created': '1995-09-12T04:00:00Z', 'expires': '2027-09-11T04:00:00Z'}
  MX    ['10 aspmx.l.google.com.', '20 alt1.aspmx.l.google.com.']
  DMARC ['"v=DMARC1; p=reject; pct=100; fo=1; rua=mailto:dmarc-reports@stripe.com; ...']
spiegel.de None
  MX    ['0 spiegel-de.mail.protection.outlook.com.']
  DMARC ['"v=DMARC1; p=quarantine; rua=mailto:report.dmarc@spiegel.de; ...']

Two facts fall straight out: Stripe's mail goes to Google (aspmx.l.google.com), Der Spiegel's to Microsoft 365 (mail.protection.outlook.com). And .de has no RDAP server in IANA's bootstrap, so rdap() returned None.

Step 2: The pitfalls

ccTLDs are a patchwork. Some have RDAP, some only port-43 WHOIS with their own text format, and some publish no dates at all. .de doesn't publish registration dates. A few registries (for example .es) offer no public RDAP or WHOIS.
"Registrable domain" isn't "last two labels". news.bbc.co.uk belongs to bbc.co.uk, not co.uk. Use the Public Suffix List, not string splitting. The same goes for turning emails and URLs into domains.
Registrant data is mostly redacted since GDPR. Expect the organisation and country at best.
DNS answers need cleaning. MX records come with a priority prefix and trailing dot. TXT records come quoted and can be split into chunks.
Email provider is inference. You map MX hosts (google.com, outlook.com, zoho…) to providers, and SPF include:s to sending tools (HubSpot, Salesforce, SendGrid…). It's reliable for the big providers and fuzzy for self-hosted setups.
DKIM can't be listed. You can only probe common selectors, and some domains answer every selector (wildcards), which looks like a false positive.
Rate limits. Registry RDAP servers throttle bulk lookups. Add concurrency limits and backoff.

Step 3: Or use the packaged version

I packaged all of this as an Apify Actor, Bulk WHOIS & DNS Lookup. You paste domains, URLs or email addresses, and it normalises them to the registrable domain (co.uk, com.au…) and dedupes.

{
  "domains": ["stripe.com", "https://www.apify.com/store", "jane@hubspot.com", "bbc.co.uk", "notion.so"],
  "includeWhois": true, "includeDns": true, "includeWebsite": true, "concurrency": 5
}

One row per domain: registrar and IANA ID, created/updated/expiry dates, domain age in days, days until expiry, EPP status, nameservers, A/AAAA/MX/NS/TXT, SPF and its includes, DMARC record and policy, optional DKIM probing (with wildcard detection), email provider, email security gateway, email senders, DNS provider, about 50 SaaS tools detected from DNS verification records, and an optional website check (status, redirects, title, basic tech like WordPress or Shopify). It's RDAP first with WHOIS fallback.

A real run on 18 Oct 2026 with 7 inputs and every check on took about 46 seconds:

Domain	Registrar	Created	Email provider	DMARC	DNS provider	SaaS found
stripe.com	SafeNames Ltd.	1995-09-12	Google Workspace	reject	Amazon Route 53	12
openai.com	MarkMonitor Inc.	2007-01-19	Google Workspace	reject	Azure DNS	19
hubspot.com	MarkMonitor Inc.	2005-02-06	Google Workspace	reject	Cloudflare	17
bbc.co.uk	British Broadcasting Corpor…	1994-12-13	Other / self-hosted	reject	–	10
spiegel.de	–	–	Microsoft 365	quarantine	–	6

ceo@hubspot.com and https://www.apify.com in the input were normalised to their domains. Same .de story as my script: DNS and email data, no WHOIS dates.

Useful filters once it's in a sheet: domainAgeDays < 90 for new-domain risk, daysUntilExpiry < 30 for portfolio renewals, emailProvider plus dmarcPolicy for deliverability or security outreach.

Limits, honestly

WHOIS coverage depends on the registry. No dates for .de, nothing for TLDs with no public RDAP/WHOIS (you get a whoisError note plus DNS data).
Registrant fields are usually null because of privacy redaction.
Provider and SaaS detection come from DNS records, so they show what a domain has verified or routed, not what it actively uses.
The website check is slower. Turn it off for big lists and raise concurrency (up to 20).
registered: false is a strong hint, not a guarantee. Confirm at a registrar before you buy.

What it costs

$0.003 per domain ($3 per 1,000), with WHOIS/RDAP, DNS, email intelligence and the website check included. No start fee, and runs stop at your "maximum cost per run". The 7-domain test was about 2 cents. If you only need registrar and expiry, a WHOIS-only tool can be cheaper. And the script above is free.

Play fair

Some registries restrict reusing WHOIS data for marketing. Read their terms, and keep privacy laws in mind when you combine domain data with people.

What signal would you want added: MTA-STS, BIMI, CAA, something else? Tell me in the comments.

Find Companies That Just Raised Money: Parsing SEC Form D Filings from EDGAR

Ben Barazandeh — Tue, 27 Oct 2026 14:03:30 +0000

Disclosure: I'm Ben, and I built the Apify Actor mentioned later in this post. I charge per result for it. Everything in the tutorial part works with free tools too.

"Recently funded companies" lists are a staple of B2B sales, recruiting and investing. A lot of them trace back to one public source: SEC Form D.

When a US company raises money in a private placement under Regulation D, it has to file a Form D with the SEC within 15 days of the first sale. That makes it one of the earliest public signals of a raise, often before any press release. And the filing itself is structured XML with the company's address, business phone, industry, amount offered, amount sold so far and the names of its executives and directors.

Here's how to get it yourself.

Rule zero: SEC's fair-access policy

EDGAR is free and needs no key, but the SEC asks every automated client to:

send a User-Agent that identifies you with a contact email (unidentified traffic can be blocked), and
stay under 10 requests per second.

Do both from the very first request. It's polite, and it's the difference between working code and a 403.

Step 1: Find recent Form D filings and parse them

EDGAR full-text search (the same backend as the search box on sec.gov) can filter by form type and date. Each hit points to the filing's primary_doc.xml, which is the Form D itself. This script ran as-is on 25 Oct 2026:

import time, requests, xml.etree.ElementTree as ET

H = {"User-Agent": "Ben Barazandeh ben.barazandeh@gmail.com"}  # SEC fair access: identify yourself

# 1) Find recent Form D filings via EDGAR full-text search
hits = requests.get("https://efts.sec.gov/LATEST/search-index",
    params={"forms": "D", "dateRange": "custom", "startdt": "2026-10-19", "enddt": "2026-10-23"},
    headers=H, timeout=30).json()["hits"]["hits"]

for h in hits[:3]:
    acc, doc = h["_id"].split(":")
    cik = h["_source"]["ciks"][0].lstrip("0")
    url = f"https://www.sec.gov/Archives/edgar/data/{cik}/{acc.replace('-', '')}/{doc}"
    x = ET.fromstring(requests.get(url, headers=H, timeout=30).content)
    print(x.findtext(".//primaryIssuer/entityName"),
          x.findtext(".//primaryIssuer/issuerPhoneNumber"),
          x.findtext(".//industryGroup/industryGroupType"),
          x.findtext(".//offeringSalesAmounts/totalOfferingAmount"),
          x.findtext(".//offeringSalesAmounts/totalAmountSold"))
    time.sleep(0.2)  # stay far below SEC's 10 requests/second

(Use your own name and email in the User-Agent.) Output:

Opus Databento CS LLC 9176692797 Other Technology 4000000 4000000
Five Winds Income Fund LLC 7758136887 Other 40000000 0
Advanced Glass Holdings, Inc. 847-906-5300 Other 2000000 2000000

The search reported 1,269 Form D hits for that Monday-to-Friday window.

Step 2: The pitfalls

That output already shows several of them:

Not every filer is a startup. Many Form Ds come from investment funds and single-property real-estate LLCs. The usual first cut is to drop industry group "Pooled Investment Fund". It isn't perfect: "Five Winds Income Fund LLC" above reports its industry as "Other", so it would slip through that filter. Expect to eyeball names too.
Amounts aren't always numbers. totalOfferingAmount can be the word Indefinite. Amount sold can be 0 on a fresh filing, so "offering" isn't "raised".
Amendments. D/A filings repeat earlier raises. Decide whether you want them.
Messy phones. 9176692797 vs 847-906-5300. Normalise before you load a CRM.
Filtering means parsing everything. Full-text search can't filter by industry or amount, so to get "tech companies that raised $250K+" you have to download and parse every Form D in the window. That's roughly 300–500 per business day.
Related persons are a list. Executives, directors and promoters each have roles and sometimes a clarification. Flattening them sensibly takes some care.

Step 3: Or use the packaged version

I packaged this as an Apify Actor, SEC EDGAR Scraper – Form D Funding Leads. It sends a descriptive User-Agent with a contact email, stays within SEC's rate limits and retries with backoff on throttling. Pooled investment funds are excluded by default.

{ "mode": "formD", "filedWithinDays": 7,
  "industryGroups": ["Technology", "Biotechnology", "Health Care"],
  "minAmountSold": 250000, "maxItems": 200 }

Every lead is the whole Form D, flattened: entity type, state and year of incorporation, address, phone, industry group, revenue range, exemptions (506(b)/506(c)/504), date of first sale, securities offered, minimum investment, offering/sold/remaining amounts, investor counts, sales commissions and finders' fees, related persons with roles, and links to EDGAR.

A real run on 18 Oct 2026 (filed in the last 7 days, max 25, funds excluded) saved 20 leads in 24 seconds. A few rows:

Company	Industry	Offering	Sold so far	City
Knowable Labs, Inc.	Other Technology	$310K	$310K	Saratoga, CA
Lamina Surgical, Inc.	Other Health Care	$5M	$490K	Oakland, CA
StrikeArc Labs Inc.	Other	$500K	$500K	Birmingham, MI
Eden X LLC	Other Real Estate	$25M	$0	Lexington, KY

There's also a second mode, filings search: EDGAR full-text search across any form type (8-K, 10-K, S-1, Form 4, 13D…), with 8-K item codes translated to plain English. For example, 8-K "material cybersecurity incident" disclosures in the last 30 days:

{ "mode": "filings", "forms": ["8-K"], "query": "\"material cybersecurity incident\"", "filedWithinDays": 30 }

For a daily feed, schedule it with filedWithinDays: 1 (or 2) and send rows to Sheets, a CRM or Slack.

Limits, honestly

Form D isn't every raise. Companies that raise under other exemptions, or that file late or not at all, won't appear.
The fund filter is a first cut. Pooled funds are excluded by industry group, but funds and real-estate LLCs that report another industry (like "Other") still get through. My sample above includes a $25M real-estate LLC.
No emails. Form D has a business phone and named people, not email addresses.
Industry groups are coarse. "Other Technology" covers a lot. Pair it with a keyword or a quick look at the website.
Industry or amount filters are slower. Every Form D in the window has to be parsed, so expect roughly a minute per day of filings.
US filers only, and not affiliated with the SEC.

What it costs

$0.005 per Form D lead ($5 per 1,000), fully parsed
$0.002 per filing in filings-search mode ($2 per 1,000)

No start fee. Filtered-out filings are free, and runs stop at your "maximum cost per run". The 20-lead test above was 10 cents in lead charges. Cheaper Form D Actors exist on the Store; I chose to parse the whole form and add the full-text mode. The DIY script above costs nothing.

Play fair

The people named in a Form D are real people. Cold outreach is covered by CAN-SPAM, TCPA and, for EU/UK contacts, GDPR. Keep it relevant, and honour opt-outs.

What would you add to a Form D lead: a website lookup, a funding-round guess, or something else? Tell me in the comments.

Track New Jobs at Your Target Companies Straight From Their ATS (Greenhouse, Lever, Ashby, Workday)

Ben Barazandeh — Mon, 26 Oct 2026 20:27:05 +0000

Disclosure: I'm Ben, and I built the Apify Actor mentioned later in this post. I charge per result for it. Everything in the tutorial part works with free tools too.

If you sell to companies that are hiring, recruit into them, or just want to know when a particular team opens a role, the company's own careers page is the best signal you can get. It's first-party and current, and you don't get job-board reposts or listings that expired three weeks ago.

The nice surprise is that you rarely need to scrape HTML to read it. Most careers pages are a thin skin over an Applicant Tracking System (ATS), and most ATSs publish a public JSON feed for exactly this purpose.

Step 1: Find the ATS behind a careers page

Open the careers page, click any job, and look at the URL:

URL looks like	ATS	Public feed
`boards.greenhouse.io/stripe` or `job-boards.greenhouse.io/...`	Greenhouse	`boards-api.greenhouse.io/v1/boards/{slug}/jobs`
`jobs.lever.co/spotify`	Lever	`api.lever.co/v0/postings/{slug}?mode=json`
`jobs.ashbyhq.com/openai`	Ashby	`api.ashbyhq.com/posting-api/job-board/{slug}`
`nvidia.wd5.myworkdayjobs.com/...`	Workday	POST search endpoint per tenant

The slug in the URL is what you pass to the API.

Step 2: Call the feeds yourself

These three calls worked when I ran them on 25 Oct 2026:

# Greenhouse: every open job at Stripe
curl -s "https://boards-api.greenhouse.io/v1/boards/stripe/jobs" \
  | python3 -c "import json,sys; j=json.load(sys.stdin)['jobs']; print(len(j), j[0]['title'], '|', j[0]['location']['name'])"

# Lever: Spotify
curl -s "https://api.lever.co/v0/postings/spotify?mode=json" \
  | python3 -c "import json,sys; j=json.load(sys.stdin); print(len(j), j[0]['text'])"

# Ashby: OpenAI, with structured compensation
curl -s "https://api.ashbyhq.com/posting-api/job-board/openai?includeCompensation=true" \
  | python3 -c "import json,sys; j=json.load(sys.stdin)['jobs']; print(len(j), j[0]['title'])"

The output was 719 jobs at Stripe, 90 at Spotify and 793 at OpenAI. No key, no login, no browser.

Step 3: The pitfalls

Once you go past three companies, this is where the time goes:

Every ATS has its own schema. Greenhouse gives you location.name, Lever categories.location, Ashby location plus secondaryLocations. Department, remote flag and employment type all have different names and shapes. You'll write a normaliser per ATS.
Salary is only sometimes structured. Ashby, Lever and Recruitee can return min/max/currency. Elsewhere, if the company publishes pay at all, it's buried in the description HTML and you have to parse ranges like "$250K - $445K" yourself.
Lever has an EU host. Some companies live on jobs.eu.lever.co and need the EU API host (api.eu.lever.co) instead.
Workday is the awkward one. Each tenant has its own host and site name, you POST a search, and it caps at about 2,000 results per search. For a big employer you need keyword searches to reach specific roles.
"New jobs" needs a date. To get a "posted today" feed, you need each ATS's published/updated date, which also differs per platform. Dedupe on the ATS job ID.
Be gentle. These are public feeds, but one request per board per day is plenty for monitoring.

None of it is hard. It's just a lot of small adapters.

Step 4: Or use the packaged version

I wrapped seven ATSs (Greenhouse, Lever, Ashby, Workday, Workable, SmartRecruiters and Recruitee) into one Apify Actor, Career Site Jobs API. You can pass career URLs, ats:slug, or just a bare company name, and it tries to detect the ATS:

{
  "companies": ["https://jobs.ashbyhq.com/openai", "https://boards.greenhouse.io/airbnb",
                "https://jobs.lever.co/spotify",
                "https://nvidia.wd5.myworkdayjobs.com/NVIDIAExternalCareerSite", "stripe"],
  "keywords": ["engineer"],
  "maxItemsPerCompany": 3
}

Every row has the same fields whatever the ATS: company, ats, jobId, title, department, location, remote, employmentType, salaryMin, salaryMax, salaryCurrency, postedAt, url, applyUrl, description and a few more. Fields an ATS doesn't publish come back as null.

Here's what that input returned in a real run on 17 Oct 2026 (15 jobs, about 7 seconds). The log reported 814 open jobs at OpenAI, 173 at Airbnb, 82 at Spotify, 732 at Stripe (auto-detected from the plain name stripe), and 2,000 at NVIDIA, which is Workday's search cap, not the real total.

ATS	Company	Title	Location	Salary
ashby	openai	Research Engineer	San Francisco	$250K - $445K
greenhouse	Airbnb	Engineering Manager, Guest & Host	London, United Kingdom	–
lever	spotify	AV Engineer - Platform	Stockholm	–
workday	nvidia	Director, Engineering – Software Engineering	Vietnam, Hanoi	–
greenhouse	Stripe	AI Engineer	Chicago	–

(The counts differ from my 25 Oct curl calls above because boards change daily. That's the point of reading them live.)

Filters: title keywords to include or exclude, location with aliases (United States also matches entries like US, CA, Santa Clara), remote only, department, and postedWithinDays. Each run also writes a per-company SUMMARY record with the detected ATS, jobs on the board, jobs saved and any errors.

The setup I'd actually use

Put your 20–200 target accounts in companies.
Set postedWithinDays: 1 (or 2, to be safe with time zones).
Schedule it daily in Apify and connect Google Sheets, Slack or a webhook.

You get a morning list of the roles each target company opened yesterday. If you set includeDescription: false, runs are lighter and faster.

Limits, honestly

It isn't a job board. It reads the companies you give it. It can't search "all companies hiring Rust engineers".
Seven ATSs only. iCIMS, Taleo, SuccessFactors, custom in-house career sites and LinkedIn/Indeed aren't covered.
Workday tops out around 2,000 jobs per search. Add keywords for very large employers.
Salary only where the company publishes it. In the sample above, only the Ashby rows had pay.
Auto-detection by name can miss. If acme isn't found, paste the careers URL instead.

What it costs

$0.002 per job ($2 per 1,000), with no start fee. You pay only for jobs saved after your filters, and the run stops cleanly at your "maximum cost per run". The 15-job test above was 3 cents in job charges. The DIY route costs nothing but your time.

Play fair

Use the data in line with each company's terms, and don't use hiring signals to spam recruiters or hiring managers. A short, relevant note beats a sequence of ten.

Which ATS or Workday tenant breaks for you? I'd love to collect edge cases in the comments, especially tenants with odd site names.

Local Business Leads Without Scraping Google Maps: An OpenStreetMap + Overpass Guide

Ben Barazandeh — Sun, 25 Oct 2026 19:34:25 +0000

Disclosure: I'm Ben, and I built the Apify Actor mentioned later in this post. I charge per result for it. Everything in the tutorial part works with free tools too.

If you sell to local businesses (web design, SEO, payments, insurance, supplies), you need lists like "every roofer in Denver with a phone number". Most people reach for a Google Maps scraper. That works, but Google's terms forbid scraping, and you aren't allowed to store or resell what you collect. That's a shaky foundation for a CRM you plan to keep for years.

There's an open alternative a lot of people overlook: OpenStreetMap.

Why OpenStreetMap?

OpenStreetMap (OSM) is the community-built world map behind thousands of apps. Its data is licensed under the Open Database License (ODbL). You can store it, reuse it and even resell it, as long as you:

keep any database you publish from it under the ODbL too (share-alike).

OSM is full of businesses: shops, restaurants, clinics, offices and tradespeople, tagged with things like amenity=dentist, craft=plumber or shop=bakery. Many have phone, website, opening_hours and sometimes email (or contact:* variants).

Here are the trade-offs up front:

	OpenStreetMap	Google Maps scrapers
Licence	ODbL: store and reuse with attribution	Google ToS forbid scraping and storing
Ratings and reviews	Not in OSM	Yes
Coverage	Very good in Europe and big cities, uneven for trades in small towns	Most complete

If you need star ratings, OSM can't help. If you need a contactable list you can actually keep, it's worth a look.

Step 1: Query OSM yourself with Overpass

The Overpass API is a read-only query engine over OSM data. The basic pattern for a lead list is:

find the city's administrative boundary and turn it into an area
ask for every node, way and relation (nwr) with your tag inside that area
get back tags plus a centre point

A minimal Overpass QL query looks like this:

[out:json][timeout:60];
area["boundary"="administrative"]["name"="Denver"]->.city;
nwr["craft"="plumber"](area.city);
out center tags;

Paste it into overpass-turbo.eu to see results on a map. In a real pipeline you'll quickly hit the annoying parts:

Ambiguous names. Lots of places are called "Denver" or "Manchester", so you need to pin down the right boundary (country, state, admin_level).
Busy public servers. Public Overpass instances often reply "try again later". You need retries with backoff, and ideally failover between servers.
Usage policies. Public instances are run by volunteers and companies, each with its own policy. overpass-api.de, for example, asks commercial users to self-host or pay. Read the policy before you point a business workload at a server.
Messy tags. phone vs contact:phone, several values separated by ;, websites without https://, and addresses split across addr:* tags.
Deduplication when you combine several categories or cities.

None of this is hard, but it adds up to a weekend of work.

Step 2: Or use the packaged version

I packaged all of that into an Apify Actor, Local Business Leads. The input is plain English:

{
  "categories": ["plumber", "electrician", "hvac", "roofer"],
  "locations": ["Denver, CO"],
  "enrichWebsites": true,
  "maxItems": 100
}

What it does:

95 built-in categories (dentist, hvac, hair salon, lawyer, accountant, gym, veterinarian, hotel…), plus any raw OSM tag such as shop=bakery, craft=* or cuisine~pizza
Resolves "Denver, CO" to Denver's official city boundary in OSM, so it doesn't spill into the next town. It can also search a radius around a lat/lng.
Resolves locations with Overpass itself, without calling the public Nominatim geocoder
Uses only public Overpass instances whose published policy allows use in any project: VK Maps and Private.coffee. It doesn't use overpass-api.de. Queries run one at a time, with exponential backoff and failover. For big or frequent jobs you can plug in your own Overpass endpoint.
Puts contact-rich leads first, and can filter to businesses that have a phone, website, email or any contact

Here's one real lead from a Denver roofers run (trimmed):

{
  "name": "Assurance Contractors",
  "category": "roofer",
  "address": "1660 South Albion Street Suite 339, Denver, CO 80222",
  "phone": "+1-720-837-1630",
  "email": "service@assurancecontractors.com",
  "website": "https://assurancecontractors.com/roofing-denver-co/",
  "openingHours": "Mo-Fr 09:00-17:00; Sa-Su closed",
  "latitude": 39.6863292,
  "longitude": -104.9391307,
  "osmId": "node/9053239725",
  "osmUrl": "https://www.openstreetmap.org/node/9053239725",
  "lastEditedAt": "2023-09-20T05:33:48Z",
  "websiteEmails": ["info@assurancecontractors.com"],
  "websitePagesFetched": 3,
  "attribution": "© OpenStreetMap contributors, ODbL 1.0 – https://www.openstreetmap.org/copyright"
}

Each row also has address parts, socials (Facebook, Instagram, LinkedIn, X, YouTube, TikTok), brand, operator, cuisine, wheelchair access and a Wikidata ID where they're mapped. Every row carries an attribution field, an OSM link and a last-edited date, so you can see how fresh the entry is.

Step 3: Be honest about coverage

This is the part most lead tools skip. Here are real fill rates from my live test runs on 17 Oct 2026:

Search	Leads	Phone	Website	Email
Restaurants + cafés, Manchester UK (only with phone or website)	200	55%	87%	17%
Plumbers/electricians/HVAC/roofers, Denver CO + enrichment	32	46%	43%	25%
Dentists, Austin TX + enrichment (capped at $0.05)	10	100%	100%	60%
`shop=bakery` within 2 km of central Paris	25	80%	88%	24%

The pattern is clear. Food, shops, healthcare and hotels in big cities are well mapped. Trades in US cities are thin. 32 trade businesses across four categories in Denver is far fewer than Google would show. There are also no ratings or reviews. Use OSM where it's strong, and don't expect it to replace Google for every niche.

Step 4: Fill in emails from each business's own website

Email is the field OSM most often lacks. The fix is to visit each business's own website and read the contact details there.

With enrichWebsites: true, the Actor reads the homepage plus up to 4 contact/about/impressum pages. It stays on the business's own domain, respects robots.txt, sends at most 1 request per second per site and uses an identifiable User-Agent. In the Denver run, enrichment roughly doubled email coverage, from 12% (OSM tags alone) to 25%.

If you're building this yourself, the same rules apply: be polite, stay on the business's own domain, and honour robots.txt.

Export and automate

Results land in an Apify dataset that you can download as CSV, Excel or JSON, or push to Google Sheets, HubSpot, Make, Zapier or n8n. To keep a list up to date, schedule a monthly run per city and dedupe on osmId.

What it costs

$0.003 per lead ($3 per 1,000)
$0.002 per website enriched ($2 per 1,000), charged only when enrichment is on and the site was reached

You pay only for leads returned, and runs stop cleanly at your "maximum cost per run". The Austin dentist test stopped at 10 leads + 9 enrichments = $0.048. The free route (Overpass plus your own crawler) costs nothing but time.

Play fair

Credit "© OpenStreetMap contributors" when you use the data publicly, and remember the share-alike rule if you publish a derived database.
Contact data comes with obligations. GDPR, CAN-SPAM, CASL and PECR rules apply to cold email. Honour opt-outs.
Go easy on the public Overpass servers. Self-host or pay for an endpoint if you run big jobs.
If a business's details in OSM are wrong, fix them on openstreetmap.org. The map gets better for everyone.

Did a city come back thin, or do you have thoughts on the Overpass usage? Tell me in the comments. I'm especially keen to hear from OSM folks.