DEV Community: Nikita Iakovlev

How to export 50,000 Agoda and Booking.com hotel reviews (and what it costs in 2026)

Nikita Iakovlev — Thu, 24 Sep 2026 01:58:49 +0000

If you work on hotel analytics, reputation software or an AI travel assistant, sooner or later you need guest reviews in bulk — not five hotels, but whole cities. In Southeast Asia that means Agoda: it's the dominant OTA in the region, and its hotel pages also show the Booking.com review pool.

This is a short guide to getting that data as clean rows, and what it costs at volume.

What one review row contains

With the Agoda Reviews Scraper on Apify, each review becomes one flat row:

rating and review text (positive and negative parts)
traveler type (solo, couple, family, business)
room booked and length of stay
reviewer country and review date
source: Agoda or Booking.com
the hotel's reply, if there is one

Filters let you keep only certain languages, a minimum rating, or reviews since a given date. You can also pull hotel records (address, rating, review counts) and live room rates for your dates in the same run.

Step by step

Open a hotel on agoda.com and copy the URL, e.g. https://www.agoda.com/the-magani-hotel-and-spa/hotel/bali-id.html.
Paste one or many URLs into the Actor input and choose "Reviews only".
Run it in the Apify Console, or call it from code:

curl -X POST "https://api.apify.com/v2/acts/lergassy~agoda-reviews-scraper/run-sync-get-dataset-items?token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"startUrls":["https://www.agoda.com/the-magani-hotel-and-spa/hotel/bali-id.html"],"mode":"reviews"}'

Export as CSV, JSON or Excel, or send rows to Google Sheets, a webhook or your database.

For a whole city, schedule one run per batch of hotels and let it collect overnight. If you use n8n, there's a ready workflow that appends new reviews to Google Sheets every Monday.

What 50,000 reviews cost

Pricing is per review: $0.003, with no per-run fee, and rows that fail are not charged. 50,000 reviews = $150.

For comparison, the most-used Agoda reviews Actor on Apify Store (as of September 2026) charges $0.006 per review plus $0.02 per run — about $302 for the same 50,000 reviews split over 100 runs. Some smaller Actors ask less per row, so compare fields and reliability, not just price: this one returns both the Agoda and the Booking.com review pools from one page, which saves a second integration.

Using it from an AI agent

The Actor is available to AI agents through the Apify MCP server and supports x402 agent payments, so an agent can find it, pay per run in USDC and get rows back without an API key setup.

Limits, honestly

It reads reviews that Agoda shows publicly; it can't see deleted or hidden ones.
Very large hotels have thousands of reviews — set a per-hotel limit if you only need recent ones.

If you need Trip.com or Google Hotels too, there are sister Actors with the same row format: Trip.com Scraper and Google Hotels Scraper.

Disclosure: links to Apify in this post use my referral code.

I cut my scraper's price 6x — the pricing mistake I'd made

Nikita Iakovlev — Mon, 21 Sep 2026 13:07:45 +0000

I run a small portfolio of scrapers on Apify. One of them pulls flight data out of Google Flights — fares, the full 100–150 itinerary list Google's own endpoint returns, the price calendar for up to a year, Explore destinations, booking options with seller prices.

I priced it the obvious way: a small fee per route searched, plus a fee per row returned. $0.01 per search, $0.001 per row. Both numbers look tiny.

Then I ran the real basket. A customer sweeping 1,000 routes and getting ~50 itineraries each — 50,000 rows — pays $60. The same job on the most popular Google Flights Actor in the category costs $30.60. I was the most expensive tool in a category where I had the best review score and almost no users.

The mistake is the double charge

A search and the rows it produces are one unit of work. Charging for both means the heavy user — the only user who pays real money — is punished exactly for the behaviour you want from them. Every serious competitor charges once: per row, or per search, never both.

Here is the same basket across the category, measured on public pricing on 21 September 2026, Free-plan tier, every run and page fee included:

Actor	50,000 flight rows
mine, before	$60.00
competitor A (per row + run fee)	$50.50
category leader (per page)	$30.60
competitor B (per row, deep tier discounts)	$12.00

So: the per-search fee is gone. One event, $0.0002 per row — $0.20 per 1,000 flights. No run fee, no page fee, no proxy fee. Error rows and empty results are free, as they always were. The same 50,000-row job is now $10, and the platform's own plan tiers take it to $5.

Measure the cost before you cut the price

What made the cut safe was fifteen real runs, read from the API rather than guessed:

$0.000011–0.000034 per row, including residential proxy.
Proxy traffic: 0.045 MB per 100 rows. The Actor talks to Google's JSON endpoint, so there is no browser and no page weight.
Margin at the deepest discount tier: 6x. At the top tier, 13x.

If you price before you measure, you are guessing in both directions at once: you either leave money on the table or sell below cost to the one customer who finally scales.

Two things I'd tell anyone pricing a pay-per-event scraper

1. Price the basket, not the event. Write down what your biggest realistic customer does in a month, then compute that single number for you and for every competitor. The per-event price tells you nothing — $0.03 per page can be cheaper than $0.001 per row, and usually is.

2. Check who pays the platform bill. Some Actors advertise $0.05 per 1,000 rows and pass compute and proxy usage to the buyer's own account on top. That is not a cheaper tool, it is a different invoice. Chasing that headline number is how you end up pricing below your own costs to beat a competitor who has no costs.

The third thing, which I'm testing now: the pricing page is a marketing surface. Three of the four most-used Actors in this category put the price in the title — $1/1K, ~$0.05/1K, $3.00/1k. Mine listed features. That is a free position in a buyer's mind and I was not using it.

The Actor, if you want to look at the shape of it: Google Flights Scraper. Feedback and feature requests genuinely decide what I build next — the last four features all came from one.

Scraping Meta's Ad Library Without a Browser: the 200 OK That Means Blocked

Nikita Iakovlev — Fri, 18 Sep 2026 21:43:07 +0000

Meta publishes every ad running on Facebook and Instagram in its Ad Library, and offers an official API only for political ads, behind an identity review. So everyone else scrapes the page.

Most of the tools that do it drive a whole headless browser, and you can see the cost of that decision from the outside: on Apify, every Actor in this niche that runs with 4 GB of memory sits at a couple of hundred monthly users, while the ones above a thousand run in 128 MB to 1 GB — two of the three biggest in 512 MB and 128 MB. A browser does not fit in 128 MB. The leaders are not rendering anything.

Here is what they are doing instead, and the four traps between you and the same result. All of it measured on 19 September 2026.

The challenge is on the page, not on the API

Request facebook.com/ads/library?q=nike from a server and you get a 481-byte document that is not the Ad Library:

<!DOCTYPE html><html><head><title>Ad Library</title></head><body>
<script>
  function executeChallenge() { fetch('/__rd_verif...

A JavaScript challenge. That single response is why so many implementations reach for a browser — and it is a wrong turn, because the challenge guards the HTML page and nothing else.

The page's own data comes from facebook.com/api/graphql/, which has no challenge. It needs one thing: an LSD token, which any ordinary facebook.com response carries in its inline config.

const home = await client.fetch('https://www.facebook.com/');
const html = await home.text();
const lsd = html.match(/"LSD",\[\],\{"token":"([^"]+)"/)[1];
const rev = html.match(/"__spin_r":(\d+)/)?.[1];

Then post the Ad Library's own query with it:

const body = new URLSearchParams({
  av: '0', __user: '0', __a: '1', __req: '3', dpr: '1', __rev: rev, lsd,
  fb_api_caller_class: 'RelayModern',
  fb_api_req_friendly_name: 'AdLibrarySearchPaginationQuery',
  server_timestamps: 'true',
  doc_id: '24394279933540792',
  variables: JSON.stringify({
    activeStatus: 'ACTIVE', adType: 'ALL', countries: ['US'],
    queryString: 'nike', first: 30, cursor: null,
    searchType: 'KEYWORD_UNORDERED', sessionID: crypto.randomUUID(),
    // …the rest of the page's own variables
  }),
});

const res = await client.fetch('https://www.facebook.com/api/graphql/', {
  method: 'POST',
  headers: {
    'content-type': 'application/x-www-form-urlencoded',
    'x-fb-lsd': lsd,
    origin: 'https://www.facebook.com',
    referer: 'https://www.facebook.com/ads/library/',
  },
  body: body.toString(),
});

Thirty ads, page_info.end_cursor for the next page, 8.2 KB per ad, 3.5 seconds per request. No browser, no rendering, no 4 GB.

Use an HTTP client that presents a real TLS fingerprint — impit, curl-impersonate, tls-client. Plain fetch has its own handshake and gets a different answer.

Trap 1: the empty 200

This is the one worth the whole article.

From a datacentre address, that GraphQL call does not fail. It returns:

HTTP 200
Content-Length: 0

No error, no status code to branch on, no message. Just nothing. Measured side by side on the same query:

Exit address	Home page	GraphQL	Ads
Server, direct	200, 455 KB	200, empty	0
Datacentre proxy, US	200, 455 KB	200, empty	0
Residential proxy, US	200, 455 KB	200, 245 KB	30

The home page loads fine from every address, which makes it worse: your session looks healthy right up to the query that matters.

If your code treats an empty parse as "no ads matched this search", you will ship something that quietly returns nothing for every search and reports success while doing it. That is not hypothetical — "returning no ads results" and "actor gives incomplete data" are recurring complaints on the popular scrapers in this niche, and this is what it looks like from the inside.

if (!text.trim()) throw new Blocked('Meta answered 200 with an empty body — this exit is not being served');

An empty body from an endpoint that always returns JSON is a block. Say so.

Trap 2: two filters Meta accepts and ignores

The Ad Library query takes a date range and a media type. It does not honour either one.

Measured on meal kit, United States, asking for ads that started after 1 September 2026: of the first 30 ads returned, 28 started earlier — one of them in March 2025. Asking for videos only on skincare: of 30 ads, 14 had no video at all.

No error, no warning. The parameters are accepted and the unfiltered result comes back.

Every scraper in this niche carries the matching complaint — "Filter on Active ads not working", "Mediatype prefilter issue (video)" — and they are all downstream of this. Re-apply the filters on your side:

function passes(ad, { startDate, mediaType }) {
  const started = ad.start_date
    ? new Date(ad.start_date * 1000).toISOString().slice(0, 10) : null;
  if (startDate && (!started || started < startDate)) return false;
  if (mediaType === 'video' && !hasVideo(ad)) return false;
  return true;
}

Then report the ratio, because it is large and your user is paying for the traffic either way. One run asking for 20 date-filtered ads read 181 ads from Meta and discarded 161 of them. A user who sees scanned: 181, filteredOut: 161, delivered: 20 understands the run. A user who just sees 20 rows after seven page fetches suspects the scraper.

Cap the paging while you are there. A filter that matches nothing will otherwise walk the whole result set.

Trap 3: the media is inside the cards

A carousel or catalogue ad (DPA, DCO) has empty snapshot.images and snapshot.videos. The media lives one level down:

const cards = snapshot.cards || [];
const videos = [...(snapshot.videos || []), ...(snapshot.extra_videos || [])]
  .map(v => v?.video_hd_url || v?.video_sd_url)
  .concat(cards.map(c => c?.video_hd_url || c?.video_sd_url))
  .filter(Boolean);

Read only the top level and a video ad arrives with no video URL — which then makes your own media filter look broken when it is working correctly. I shipped exactly that bug and found it by testing the promise, not the code.

While you are in snapshot: catalogue ads keep their template placeholders. A live Nike ad's headline is literally {{product.name}}, because the real product is substituted at delivery and the Ad Library stores the template. Pass it through, but flag it — a user counting headlines needs to know those are not copy.

Trap 4: spend and reach do not exist for commercial ads

spend, currency, reach_estimate and impressions_with_index are null on every ordinary ad. They are not missing because of your request. Meta publishes them only for ads it has classified as political or social-issue, which is also the only shelf its official API covers.

Ask for that shelf with adType: 'POLITICAL_AND_ISSUE_ADS' and the same fields fill in:

{ "page_name": "Meta", "spend": ">$1M", "currency": "USD",
  "impressions_with_index": { "impressions_text": ">1M" },
  "reach_estimate": ">1M", "categories": ["POLITICAL"] }

Ranges, not numbers — that is Meta's own granularity. Which means any tool showing you an exact spend figure for a commercial ad is showing you something it made up. One review on a popular scraper reports an ad spend "around 100 billion"; that is what an invented number looks like when it reaches a user.

What the shape of this tells you

Four of these five problems return HTTP 200 and plausible-looking data. The block, the ignored filters, the empty media array — none of them raise anything. Only the missing spend column is visibly absent, and that one is not a bug at all.

That is the actual lesson for scraping a large platform: the failures that cost you users do not throw. Test the promise — ask for ads after a date and check the dates that came back, ask for videos and count the video URLs, run the same query from two different networks and compare. The code passing its own tests tells you nothing about whether the platform answered you honestly.

The scraper these came out of is Meta Ad Library Scraper: ads from Facebook and Instagram as flat rows, filters re-checked on delivery, and a run summary that says how many ads were read, how many were discarded and why it stopped.

Why Your YouTube Transcript Scraper Says 'No Captions Found' on a Video That Has Captions

Nikita Iakovlev — Fri, 18 Sep 2026 15:58:02 +0000

Spend an hour in the issue trackers of the popular YouTube transcript tools and one complaint drowns out the rest. Someone pastes a URL, gets No caption was found!, opens the video in a browser, turns captions on, and they are right there.

I went through 30 issues on the most-used transcript Actor on Apify — it carries a 3.7 rating across 49 reviews, which is what that class of bug does to a listing — and then hit every one of them myself while building a competitor. Four distinct causes, none of them obvious, all of them cheap to fix once you know what you are looking at.

1. The language code is not the language code

This is the big one.

YouTube's caption map does not use bare language codes. A video with English subtitles written by its uploader has en. A video with English subtitles contributed by a viewer, or auto-translated, has something like:

en-eEY6OEpapPo

That suffix is a track identifier, not a locale. Despacito — 9.1 billion views, captions in dozens of languages — serves its English track under exactly that key.

So this, which is what most implementations do:

track = subtitles.get(language)   # language = "en"

returns None on a video that plainly has English captions, and the user gets told there are none.

Match by prefix, and prefer the plainest label when several qualify:

def find_track(source: dict, wanted: str):
    keys = sorted(source.keys(), key=lambda k: (len(k), k))
    exact    = [k for k in keys if k.lower() == wanted]
    prefixed = [k for k in keys if k.lower().startswith((wanted + "-", wanted + "_"))]
    for key in exact + prefixed:
        for fmt in source.get(key) or []:
            if fmt.get("ext") == "json3" and fmt.get("url"):
                return fmt["url"], key
    return None, None

Sorting by (len(k), k) puts en ahead of en-eEY6OEpapPo, so a hand-written track wins over a contributed one when both exist. Report the key you actually used back to the caller — the difference between a human translation and a machine one matters to whoever is reading the text.

2. "Just use the video's own language" is not reproducible

The obvious fix for "user asked for English, video is Spanish" is a fallback: take the language the video says it is in. yt-dlp exposes it as info["language"], so:

order = [info.get("language"), "en"] + everything_else   # looks right

I shipped that, ran it twice against the same video, and got two different transcripts. First run: es, the Spanish original. Second run, same code, same video, minutes apart: the field came back empty and the fallback moved on to English.

The field is derived from whatever player response the extraction happened to get. It varies with the client YouTube answers, and therefore with your proxy exit, the time of day, and nothing you control. It is a hint, not a fact.

If your fallback is going to be documented — and it should be, because the caller is paying for rows — it has to be reproducible. Mine ended up as a fixed order with the unreliable field demoted:

order = ["en", (info.get("language") or "").split("-")[0], *manual_codes, *auto_codes]

English first because that is what most callers want and it is a stable choice; the video's declared language second, where it helps when present and costs nothing when absent.

3. An alphabetical fallback returns German

Before I settled on that order, the fallback was "any manual track, shortest label first" — which sorts alphabetically among equals.

Run it on jNQXAC9IVRw, the first video ever uploaded to YouTube. It has community subtitles in a long list of languages. The transcript that came back:

Also hier sind wir vor den Elefanten. Das Coole an den Typen ist dass sie sehr, sehr, sehr, lange Rüssel haben.

Correct German. Completely unexpected output for an English video, and the user cannot predict it, because the reason is that de sorts before en.

Any implicit ordering becomes a product decision the moment a fallback exists. Sorting is implicit ordering.

4. Markup survives into your text

Caption tracks carry styling. Community-written ones especially:

<i>Ooh, oh, no</i>
<font color="#E5E5E5">hello</font>
Tom &amp; Jerry

For a subtitle renderer that is formatting. In a transcript headed for summarisation, keyword search or a RAG index, it is noise that costs tokens and pollutes matching. Strip tags, decode entities.

One trap in doing it. The obvious pattern:

TAG = re.compile(r"<[^>]{1,120}>")

eats arithmetic. A transcript containing a < b and c > d comes out as a d, because everything between the first < and the next > looked like a tag. Require a tag to open with a letter or a slash:

TAG = re.compile(r"</?[a-zA-Z][^>]{0,120}>")

def clean(text: str) -> str:
    return TAG.sub("", html.unescape(text))

Unescape before stripping, or <i> survives as literal text after the real tags are gone.

The fifth one, which is not about captions at all

Half the "stopped working" reports in that tracker are not caption bugs. They are one unhandled string.

Fetch a batch of videos concurrently and YouTube will drop connections. Most transient-error lists cover the usual suspects — SSL, EOF, Connection reset, timed out — and miss this one:

Remote end closed connection without response

It arrived as an ordinary exception, fell through the retry branch, and turned into a failed row. It cost me one video out of six on two separate batches before I read the message properly; with the string added, the same batch came back six for six.

A retry list is a list of literals someone wrote down once. It is worth re-reading it against what your logs actually contain, rather than what you assumed they would.

What to test before you ship

None of these show up on a happy-path video. The set that finds them:

A video whose only captions are contributed or auto-translated, so the key carries a suffix.
A video with captions in many languages and none declared — tests your fallback's determinism.
A non-English video with no English track at all.
A video with styled captions, and one whose transcript contains < or > as text.
The same video twice, minutes apart, compared byte for byte. If two runs disagree, something in your path is reading a field that is not stable.
A batch large enough that the host starts dropping connections.

The last two are the ones that get skipped, and they are the two that produce the reviews nobody wants.

The scraper these came out of is YouTube Transcript Scraper — transcripts with timecodes from videos, playlists and whole channels, SRT and WebVTT, and chunks that keep their timecodes for RAG. A video with no captions returns a free error row that lists the languages it does have, which is the honest answer to the complaint this whole article is about.

Scraping Meta Threads Without a Login — What the Search Page Actually Returns

Nikita Iakovlev — Wed, 16 Sep 2026 23:38:46 +0000

Threads has no public API for other people's content. Meta ships one for your own account, and that is it. Everything else — brand monitoring, competitor tracking, research — has to come from the pages Threads serves to a visitor who is not logged in.

Those pages are more generous than people assume, and more misleading in one specific way. Both parts matter if you are building on them.

What a logged-out visitor actually gets

Open a profile without an account and Threads renders the page server-side, with the data embedded as Relay payloads inside the HTML. No browser automation is needed to read them: one HTTP request with a believable TLS fingerprint gets you the same JSON the page uses.

From those payloads you can take:

An account's posts, paged through the same GraphQL endpoint the site calls when you scroll. Not the first 25 — a profile with 1,400 posts pages all the way down.
Replies and reposts, each with the post being answered, so a conversation can be rebuilt from flat rows.
A single post with its reply tree, parent links included.
Profiles: follower count, bio, bio links, external website, verification, linked Instagram, and any e-mail or phone the owner put in the bio.
Keyword and hashtag search, from the top, recent and tag result pages.

Every post carries text, timestamp, author, likes, replies, reposts, quotes, media URLs, links, mentions and hashtags. That is a complete social dataset, from a site with no public API, without a single browser.

The part that quietly breaks analyses

Threads' logged-out search pages return posts that do not contain your query at all.

Not a handful of edge cases — measured on 16 September 2026 for the query apify:

Result page	Results	Actually containing the word
Recent	22	20
Top	22	17
Hashtag page	26	7

The hashtag page is mostly noise. And an earlier run of the same query on the recent page returned five posts, all published in the same second, in five different languages, none mentioning the query — a global firehose, served as if it were a search result.

If you are counting brand mentions, that is not a rounding error. It is a number that is wrong by a factor of two or three, in the direction that makes your dashboard look busier.

The fix is not clever, it just has to be there: after fetching, keep only posts whose text or hashtags actually contain the query — the whole phrase, or every word of it for multi-word queries. Anything that does not pass is dropped before it is counted, stored, or billed.

def is_mention(post, query):
    hay = (post["text"] + " " + " ".join(post["hashtags"])).lower()
    q = query.lower().lstrip("#").strip()
    if q in hay:
        return True
    words = [w for w in q.split() if len(w) > 1]
    return len(words) > 1 and all(w in hay for w in words)

Why view counts are null, and why that is the honest answer

Threads shows a view count on a handful of posts to logged-out visitors, and hides it on the rest. Some scrapers fill the gap with a zero. That single decision quietly destroys any filter built on it: ask for "posts with at least 1,000 views" and you get an empty dataset, because almost every row was assigned a zero.

Null is the correct value for "the platform did not tell us". Filter on likes or replies, which are always there.

The same rule applies to search depth. Threads shows a logged-out visitor roughly one page per query and result type, with no cursor. You can widen the net by asking in more ways — singular and plural, with and without the hash, top and recent — and deduplicating by post id, which in practice triples the unique posts you get. What you cannot do is promise thousands of results per keyword, and anyone who does is either logged in or counting duplicates.

A scraper on a schedule is the wrong tool

Here is the pattern almost everyone builds first: point a scraper at an account, run it hourly, store everything, deduplicate later.

Run the numbers. Twenty-five posts per check, twenty-four checks a day, thirty days: 18,000 rows a month per account, of which maybe 60 are new. You paid for all 18,000, and you wrote the deduplication yourself.

The alternative is to make "what changed" the product rather than a post-processing step. A named watch keeps the set of post ids it has already delivered in a key-value store. Every run fetches the top of the feed, subtracts what it has seen, delivers the difference, and writes the union back:

const store = await Actor.openKeyValueStore(`threads-watch-${name}`);
const seen = new Set((await store.getValue('seen')) || []);

const fresh = posts.filter((p) => !seen.has(p.id));
for (const p of posts) seen.add(p.id);

await Actor.pushData(fresh);
await store.setValue('seen', [...seen]);

Twelve lines, and the economics invert: you pay for the 60 new posts instead of the 18,000 repeats, and an hour when nothing was posted costs nothing at all. The same trick works for prices, job listings, and anything else you check more often than it changes.

Two details make it survive contact with reality. First, the very first run has nothing to compare against — deliver what is there and say so on the row, rather than returning an empty dataset that reads as a bug. Second, keep filtered-out posts in the seen set. A post you decided to ignore today must not come back tomorrow as breaking news.

The legal and practical boundaries

Public pages, read the way a visitor reads them, with no login and no account of yours at risk. Public data collection is generally lawful in the EU and the US, but personal data is regulated wherever it lands, and bios contain plenty of it. That is a question for your lawyer, not for your scraper.

Practically: no login means no private accounts, no follower lists, and no direct messages. It also means nothing you run can get an account of yours restricted, which is the trade most teams would take anyway.

If you would rather not build it

Both pieces exist as ready actors on the Apify platform:

Threads Scraper — search, posts, replies, whole threads, profiles and account discovery, with the query-match filter and the null-instead-of-zero rule described above. $2 per 1,000 posts, errors free, no start fee.
Threads Monitor — the delta mode as a product: name a watch, schedule it, receive only what appeared since the last check. A run that finds nothing new is free.

Both read the same public pages this article describes. The measurements above come from real runs, not from the documentation.

I made my Apify Actor an AI agent tool, then read every byte it sent back

Nikita Iakovlev — Fri, 11 Sep 2026 05:05:36 +0000

I have about thirty Actors on the Apify Store. Making one of them available to an AI agent through the Apify MCP server took me two minutes: add ?actors=lergassy/jobs-api to the server URL and the Actor shows up as a tool. That part is a footnote.

The useful part was what came back. I spent an afternoon calling my own Actor the way an agent calls it — raw JSON-RPC over the wire, no client in between — and logging every response. Four things surprised me, and three of them changed how I write input schemas.

The Actor here is Jobs API: job listings from Indeed, LinkedIn and company career boards in one schema. Nothing about what follows is specific to jobs, though. If your Actor has more than three inputs, the same things will happen to you.

Talking to the server without a client

Every walkthrough I found used Claude Desktop or Cursor. I wanted the traffic, not a chat transcript, so I used curl. The Apify MCP server speaks streamable HTTP: you POST JSON-RPC, you get back server-sent events.

import json, subprocess, pathlib

HERE = pathlib.Path(__file__).parent
TOKEN = (HERE / "tok").read_text().strip()
URL = "https://mcp.apify.com/?actors=lergassy/jobs-api"

def post(body, sid=None):
    cmd = ["curl", "-s", "--max-time", "300", "-D", str(HERE / "h.txt"),
           "-X", "POST", URL,
           "-H", f"Authorization: Bearer {TOKEN}",
           "-H", "Content-Type: application/json",
           "-H", "Accept: application/json, text/event-stream"]
    if sid:
        cmd += ["-H", f"Mcp-Session-Id: {sid}"]
    cmd += ["-d", json.dumps(body)]
    out = subprocess.run(cmd, capture_output=True, text=True).stdout
    return [json.loads(l[6:]) for l in out.splitlines() if l.startswith("data: ")]

def session():
    post({"jsonrpc": "2.0", "id": 1, "method": "initialize",
          "params": {"protocolVersion": "2025-06-18", "capabilities": {},
                     "clientInfo": {"name": "curl-client", "version": "1.0"}}})
    sid = next(l.split(":", 1)[1].strip()
               for l in (HERE / "h.txt").read_text().splitlines()
               if l.lower().startswith("mcp-session-id"))
    post({"jsonrpc": "2.0", "method": "notifications/initialized"}, sid)
    return sid

Two things to get right or nothing works. The Accept header has to name both application/json and text/event-stream — the server rejects the request otherwise. And the session id comes back in a response header, not in the body, which is why I dump headers to a file and read them back.

With a session open, tools/list shows what the agent gets:

5 tools
- get-actor-run
- get-dataset-items
- get-key-value-store-record
- abort-actor-run
- lergassy--jobs-api

My Actor is one tool. The other four are the plumbing around it: start a run, poll it, read the dataset, kill it. That shape matters later.

The schema the agent reads is not the schema I wrote

My input_schema.json has 23 properties. The tool definition the agent receives has 24. The server adds one of its own, and it is the single most important field in the whole exchange — I will come back to it.

The rest is my schema, rewritten. Here is one property as I wrote it, and as the agent sees it:

"keywords": {
  "title": "🔎 Job titles or keywords",
  "description": "One search per line: <code>python developer</code>, <code>registered nurse</code>, <code>marketing manager</code>. Boolean syntax the boards support works too (<code>\"data engineer\" -senior</code> on Indeed).\nExample values: [\"python developer\"]",
  "type": "array",
  "prefill": ["python developer"],
  "examples": ["python developer"]
}

Three observations, all of which cost me something.

My emoji and my HTML went straight through. The 🔎 in the title and the <code> tags in the description were written for the Apify Console input form, where they render. In a tool definition they are tokens an agent pays for and markup it has to ignore. Nobody strips them. Across the whole tool my schema is 9,135 characters, and a slice of that is decoration for a form the agent will never see.

prefill gets promoted into the description. The server appends Example values: ["python developer"] to the text. That is a genuinely good move — it converts a Console nicety into an instruction — but it means the prefill field is now documentation. I had a couple of Actors where prefill was a throwaway placeholder. Those placeholders are now the example the model imitates.

required is empty. That is my fault, not the server's. My schema requires nothing, so the tool definition tells the agent that a call with zero arguments is valid. It is not: the Actor has no useful default search. An agent that believes the schema will produce an empty run, and the run will succeed while doing so.

Which is exactly what happened next.

A green run that returned nothing

My first real call, with arguments I would have called obviously correct:

{
  "keywords": ["python developer"],
  "location": "Berlin",
  "sources": ["indeed"],
  "maxJobsPerQuery": 10,
  "maxItems": 10,
  "includeDescription": false
}

The response:

SUCCEEDED in 3.297s. Dataset item count reads 0 — counts can lag right after a run
finishes. Key-value store has 1 key.
Fetch get-dataset-items with datasetId=paykg466SehjPTgFI and limit (for example 20)
before concluding the run produced no output.

I fetched them. "items": [], "itemCount": 0. Zero jobs, status SUCCEEDED, exit code 0.

The cause is embarrassing once you see it. country defaults to us, and I did not pass it. So the Actor searched Indeed US for jobs in Berlin and correctly found none. Same call with "country": "de":

SUCCEEDED in 7.874s. 10 items; 44 fields available.

Nothing was broken. The schema was: two fields have to agree with each other, and no part of the tool definition says so. A human filling in the Console form sees a country dropdown sitting next to a location box and picks the matching one. An agent reads two independent properties, one with a default, and has no reason to touch the one it did not need.

This is the difference between an Actor that works and an Actor that is agent-usable, and it is not a code change. The fix goes in the prose:

location now says, in its description, that it must be consistent with country, and names what happens when it is not — an empty result, not an error.
country no longer silently defaults to us in the description text. The default stays, because breaking existing users over this would be worse, but the description states it in the first sentence.

The thing I would do differently from the start: write field descriptions for a reader who cannot see the other fields. A form is a layout. A tool definition is a flat list.

The 45-second ceiling nobody mentions

Here is the property the server adds to every Actor tool:

"waitSecs": {
  "type": "integer",
  "minimum": 0,
  "maximum": 45,
  "default": 30,
  "description": "Max seconds (0–45, default 30) to cap the wait for the Actor run to reach terminal state..."
}

Forty-five seconds, hard maximum. A tool call cannot block longer than that. My small Berlin run finished in 7.9 seconds and fit comfortably. A realistic one does not. Three keywords, two sources, 100 jobs per query, full descriptions:

RUNNING for 5s. In progress.
Use get-actor-run with runId=jXPenvUnx5V3d5oHg and waitSecs=30 to poll for completion.

Then, polling:

RUNNING for 43s. In progress. 296 results so far.
RUNNING for 74s. In progress. 485 results so far.
SUCCEEDED in 77.813s. 485 items; 51 fields available.

Seventy-eight seconds. Three round trips. Every scraper I own that does anything substantial runs longer than 45 seconds, which means the normal path for an agent is not call tool, get data — it is start, poll, poll, fetch.

The server handles this better than I expected. Each response ends with a nextStep line naming the exact tool and the exact identifier to use next. That is why get-actor-run and get-dataset-items are in the tool list: the polling loop is not something the agent has to invent.

What it means for me as an Actor author:

Emit partial results as you go. The 296 results so far line is only there because my Actor pushes to the dataset during the run instead of at the end. An Actor that buffers everything and writes once at the finish shows 0 results so far for 78 seconds, and an agent may well give up on it.
Keep a cheap mode. A call that can finish inside 45 seconds — smaller caps, descriptions off — is worth having, because single-shot beats a poll loop every time.
Fail loudly, not emptily. An agent reads SUCCEEDED plus zero items as an answer about the world: there are no Python jobs in Berlin. That is worse than an error.

116,483 characters versus 2,579

The last measurement is the one I would put in front of anyone pricing an agent workflow.

I fetched my 10 Berlin jobs with no field selection. The response was 116,483 characters — roughly 29,000 tokens, for ten job listings, because the dataset has 44 fields per row and one of them is a full job description.

Then the same ten rows with the fields an agent actually needs to answer what Python jobs are open in Berlin:

post({"jsonrpc": "2.0", "id": 9, "method": "tools/call",
      "params": {"name": "get-dataset-items",
                 "arguments": {"datasetId": "X7bLTUTlRMIyunaI5",
                               "limit": 10,
                               "fields": "title,company,location,salaryMin,salaryMax,applyUrl"}}}, sid)

2,579 characters. Forty-five times smaller, same answer.

Note the type: fields is a comma-separated string, not an array. I passed a list first, the way my own schema takes arrays, and got:

MCP error -32602: Invalid arguments for tool "get-dataset-items".
Validation errors: /fields: must be string.

A clean, recoverable error — the agent is told the type and which path failed. That is the standard my own error messages should meet and mostly do not.

The Actor-author lesson is about field order, not about fields. The server lists available fields back to the agent in the order the dataset defines them, and a model asked to choose will lean on the first ones it reads. My wide rows now start with title, company, location, salary and apply link, and the bulky text sits at the end. It costs nothing and it moves the default behaviour in the right direction.

What I changed

Four edits, all in the input schema, none in the scraping code:

location now states the cross-field constraint in words: it has to agree with country, and a mismatch returns zero rows rather than an error. The agent has no layout to infer that from.
country leads with the fact that it defaults to us, instead of burying it under a list of sixty country codes.
keywords says it is required unless career-site boards or start URLs are filled in. I did not add it to required, because runs driven by start URLs alone are legitimate and marking it required would break them — but "call with no arguments" no longer reads as sensible.
prefill values are real, correct examples everywhere, now that I know the server promotes them into the description the model reads.

One thing I did not have to change, and only noticed because of this exercise: the Actor pushes rows to the dataset as it goes rather than at the end. That is why the polling responses said 296 results so far instead of 0. An Actor that buffers everything and writes once at the finish looks dead for seventy-eight seconds, and an agent has no way to tell that apart from a stuck run. If yours buffers, that is the highest-value fix on this list.

None of this makes an Actor smarter. It makes it legible to a caller that can only read the schema, cannot see the Console, will not notice that two dropdowns belong together, and pays by the token for everything you hand back.

If you want to look at the tool your own Actor exposes, it is one request. Point the URL at https://mcp.apify.com/?actors=<username>/<actor>, run tools/list, and read what comes back as if you had never seen your own input form. I did, and I found four things to fix in an afternoon.

Phone Number Validation Without a Paid API — What the NANPA File Actually Tells You

Nikita Iakovlev — Mon, 07 Sep 2026 06:50:19 +0000

Most phone validation in the wild is a regex that counts digits. It passes +1 999 123 4567, which can never ring, and it rejects nothing that matters.

There is a real specification underneath, and the assignment data is public. This is what it says.

The file

The North American Numbering Plan Administrator publishes the current assignment of every area code as a CSV:

https://reports.nanpa.com/public/npa_report.csv

No key, no signup. It has 800 rows — one per possible area code — with 32 columns. The ones that matter:

Column	What it holds
`NPA_ID`	the three-digit area code
`IN_SERVICE`	`Y` or `N`
`USE`	`G` geographic, `N` non-geographic (toll-free and similar)
`EXPLANATION`	e.g. `Expansion Code`
`LOCATION`	state, province or territory
`COUNTRY`	`US`, `CANADA`, `BAHAMAS`, …
`TIME_ZONE`	`E`, `C`, `M`, `P`, …

Counting the file as of 4 September 2026: 378 geographic area codes in service in the United States, and 454 across the whole plan once Canada and the Caribbean members are included. If a tool tells you "378 area codes" while also promising Canadian coverage, it counted the wrong column.

The rules a regex misses

The area code has to exist. 999 does not. It is one of 79 codes with a 9 in the middle position that the file marks Expansion Code — held back for the day the plan runs out of numbers. Every one of them fails, and every one of them passes a length check.

Area code and exchange both start with 2–9. Never 0 or 1. This one most people do get right.

The N11 codes are service codes. 911, 411, 211, 311, 511, 611, 711, 811 — never assignable as an exchange.

And then there is 555. Here is where almost everyone overcorrects. The block reserved for fiction is narrow: 555-0100 through 555-0199, and only that. 555-1212 is live directory assistance across the continent. So:

# wrong — rejects a working number
if exchange == "555":
    return "invalid"

# right — rejects only the reserved block
if exchange == "555" and 100 <= int(line) <= 199:
    return "invalid"

A validator that rejects the whole 555 exchange will quietly throw away real numbers from a real list, and you will never see it happen.

What a validated number is worth

Once a number passes, the same file hands you two fields that turn a list into a call plan:

LOCATION — the state or province of the area code
TIME_ZONE — which is what you actually wanted

Sorting a call list by the recipient's local time is the difference between a 9 a.m. call and a 6 a.m. one. One gotcha to hard-code: Arizona does not observe daylight saving. All five Arizona area codes are marked Mountain, but for eight months of the year they are an hour off Denver. Use America/Phoenix, not America/Denver, or half your calls land at the wrong hour. (The Navajo Nation inside Arizona does observe DST, which is the kind of edge case worth knowing exists and not worth solving.)

Area codes that straddle two or three time zones exist too — a couple of dozen of them carry combinations like CM or EC in the file. Treat those as "confirm before dialling", not as a single zone.

Real output

An actual run, four numbers, September 2026:

[
  { "phone": "+1 415 555 0132",
    "phoneStatus": "invalid", "phoneReason": "reserved_exchange" },

  { "phone": "+1 999 123 4567",
    "phoneStatus": "invalid", "phoneReason": "nanp_rule" },

  { "phone": "+1 646 555 0100",
    "phoneStatus": "invalid", "phoneReason": "reserved_exchange" },

  { "phone": "+62 361 123456",
    "phoneStatus": "valid", "phoneType": "international",
    "phoneReason": "structure_only", "phoneE164": "+62361123456" }
]

The last one is the honest part. 0361 is genuinely the Denpasar area code, so the number is correctly formed for Indonesia — but outside the NANP there is no equivalent public assignment file to check against. structure_only says exactly that. Any tool that claims to "validate" an arbitrary international number without saying which check it ran is telling you it checked something it did not.

What this does not give you

Line type. Whether a number is mobile, landline or VoIP is not in the assignment file. Carrier and line type come from HLR lookups, which are a paid product with per-number pricing, and the answer changes when someone ports their number.

Whether it rings. Nothing short of dialling tells you that, and dialling to find out is its own problem.

Ownership. Reverse lookup is a separate, and in most places regulated, product.

What the file does give you is the cheap half: everything that can never be a working number, removed before you pay anyone per lookup. On scraped and bought lists that is a meaningful slice, and it costs a DNS-free, API-free file read.

Running it

The Email Verifier & Phone Number Validator actor applies every rule above, plus the same treatment for email addresses in the same pass:

{
  "phones": ["+1 415 555 0132", "+1 646 212 3344", "+62 361 123456"],
  "defaultCountry": "US"
}

curl -X POST "https://api.apify.com/v2/acts/lergassy~email-phone-verifier/runs" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -d '{"phones":["+1 415 555 0132","+1 646 212 3344"]}'

It also reads another actor's dataset directly, so a scraped lead list can be validated where it already sits:

{ "inputDatasetId": "abc123def456", "phoneField": "phone", "keep": "valid_phone" }

If you build your own, the file is the whole trick: download it, index by NPA_ID, and check IN_SERVICE before anything else. It updates as codes come into service, so re-fetch it monthly rather than freezing a copy in your repo.

Actor: Email Verifier & Phone Number Validator on Apify.

The Same Seat, Three Prices: Reading Google Flights Booking Options in Python

Nikita Iakovlev — Mon, 07 Sep 2026 03:20:12 +0000

Here is a Jetstar flight from Bali to Singapore on 19 November, as Google Flights sees it:

Jetstar — 50 USD
       50 USD  (870000 IDR)         Jetstar [airline]
      119 USD  (2085182 IDR)        Qantas [airline]
      128 USD  (2251997 IDR)        Jettzy [agency]

Same aircraft, same seat, same day. Fifty dollars if you buy from Jetstar, a hundred and
twenty-eight if you buy from an agency that resells it. Google knows this and shows it
behind a click most people never make.

If you are building anything that compares fares — a price alert, a travel dashboard, an
agent that answers "when should I fly" — that seller table is the interesting part, and
it is the part most flight scrapers drop.

Why there is no easy API for this

Google shut down QPX Express in April 2018 and never replaced it. There is no public
Google Flights API. What exists is the consumer interface, which is a heavily obfuscated
single-page app, and the endpoint behind it, which returns a nested array of arrays with
no field names at all.

You can reverse that yourself — people do — or you can call something that already has.
I maintain a Google Flights Scraper
Actor on Apify that reads Google's own endpoint and returns flat rows. The three scripts
below use it, and everything printed here is a real run, not an illustration.

pip install apify-client
export APIFY_TOKEN=...   # console.apify.com/settings/integrations

Reading the seller table

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])

run = client.actor("lergassy/google-flights-scraper").call(
    run_input={
        "origin": "DPS",
        "destination": "SIN",
        "departureDate": "2026-11-19",
        "maxResults": 5,
        "resolveBookingOptions": True,   # the part that costs an extra request per flight
        "maxBookingResolutions": 3,
        "currency": "USD",
    }
)

rows = client.dataset(run.default_dataset_id).list_items().items

for flight in (r for r in rows if r.get("type") == "flight" and r.get("bookingOptions")):
    print(f"\n{flight['airline']} — {flight['price']} {flight['currency']}")
    for option in flight["bookingOptions"]:
        tag = "airline" if option["isAirline"] else "agency"
        print(f"   {option['price']:>6} USD  {option['seller']} [{tag}]")

One detail worth knowing: apify-client 3.x returns a Run object, not a dictionary.
Most tutorials online still show run["defaultDatasetId"], which now raises
TypeError: 'Run' object is not subscriptable. It is run.default_dataset_id.

Each booking option also carries localPrice and localCurrency — what the seller
charges in the currency of the point of sale — plus a direct booking URL. The local price
is not a conversion of the USD figure; it is the number that seller actually bills, and
the two drift apart.

The other two questions worth asking

Which day is cheapest? Google Flights has a price calendar in its UI. Ask for it as
rows and you can diff today's answer against yesterday's, which is what a fare alert
actually needs:

run = client.actor("lergassy/google-flights-scraper").call(
    run_input={
        "origin": "DPS", "destination": "SIN",
        "departureDate": "2026-11-10",
        "calendarDays": 45, "calendarOnly": True, "currency": "USD",
    }
)
rows = client.dataset(run.default_dataset_id).list_items().items
days = sorted((r for r in rows if r["type"] == "calendar_day" and r.get("price")),
              key=lambda r: r["price"])
print(days[0]["date"], days[0]["price"])   # 2026-11-19 50

Where can I go cheaply from here? The Explore map, as a sortable table:

     63 USD  Komodo                 Indonesia        Wings Abadi Airlines nonstop    1.5h
     91 USD  Yogyakarta             Indonesia        Lion                 nonstop    1.5h
    107 USD  Perth                  Australia        Jetstar              nonstop    3.6h
    190 USD  Brisbane               Australia        Batik Air            nonstop    5.8h

Set exploreAnywhere: True with an origin and a date, and each destination comes back
with city, country, coordinates, price, airline, stops and flight time.

Two things that will bite you

Point of sale changes the fare. A route priced from the US and the same route priced
from Indonesia are genuinely different numbers, not a currency conversion. If you are
comparing prices over time, pin market to a two-letter country code, or you will record
noise as signal.

A past date returns nothing, silently. Google sells future dates only. Any scheduled
job with a hardcoded departure date will quietly start returning empty results the day
that date passes — worth a guard in your own code regardless of which tool you use.

The scripts

All three, runnable, are on GitHub:
lergassy/google-flights-api-examples.

The Actor itself, with the full field list — layovers, aircraft, CO₂ per itinerary,
Google's own price level and the historical band behind it, multi-city, batch routes —
is at apify.com/lergassy/google-flights-scraper.

If you end up building the fare alert, the seller table is where the money is. A hundred
and twenty-eight dollars for a fifty dollar seat is not an edge case; it is Tuesday.

Email Verification Without Sending a Single Email (And Why Port 25 Is a Dead End)

Nikita Iakovlev — Fri, 04 Sep 2026 06:33:29 +0000

Every email verification service advertises the same thing: paste a list, get back deliverable or not. Almost none of them explain what they actually check, and the difference matters, because one of the checks people assume is happening is usually impossible.

Here's what's really under the hood, what each signal is worth, and the one that quietly doesn't work on any major cloud.

The check that doesn't work anymore

The textbook method is an SMTP handshake. You connect to the recipient's mail server on port 25, say HELO, MAIL FROM, then RCPT TO: <the address>, and read the response code. A 250 means the mailbox exists. You disconnect before DATA, so no mail is ever sent.

It's elegant. It's also unavailable to you.

Outbound port 25 is blocked by default on AWS, Google Cloud, Azure, DigitalOcean, Hetzner and most serverless platforms. It's an anti-spam measure and it has been standard for years. Some providers will unblock it — AWS after a request form, Google automatically for projects it scores as low-risk, Hetzner's dedicated servers by self-service after a month. DigitalOcean blocks 25, 465 and 587 with no path at all.

The point isn't that it's impossible everywhere. It's that on whatever you actually deploy to, it's probably off, and finding out after you've built the feature is expensive. I checked before building anything: on the platform I deploy to, a raw socket to gmail-smtp-in.l.google.com:25 times out from every region I tried.

Two more reasons SMTP verification is worse than it looks even when you can run it:

Catch-all domains accept everything. A large share of corporate domains return 250 for any address at all, so a positive result carries no information.
Greylisting and reputation. Repeated RCPT TO probes from one IP get throttled, then blocked. Providers treat the pattern as harvesting, because it is the same pattern harvesters use.

Which is why the honest services return a three-state answer, not a boolean. Anyone selling you a clean yes/no on a corporate domain is guessing.

What can actually be checked

Five signals, each independently useful:

1. Syntax against the real grammar. Not a regex from Stack Overflow. Length limits (64 characters local part, 254 total), consecutive dots, leading and trailing dots, quoting rules, IDN handling.

2. Domain resolution. Does the domain exist at all? An NXDOMAIN is a definite negative and the only cheap definite negative you get.

3. MX records. A domain can exist and still have no mail exchanger. No MX means nothing can receive mail there, which is again definite. This one catches more than you'd expect, including a surprising number of live business websites whose owners never finished setting up mail.

4. Disposable domain list. Mailinator, Guerrilla Mail, 10minutemail and several thousand throwaway providers, including the typo-squat domains registered specifically to catch mistyped Gmail addresses.

5. Classification. Role address (info@, support@, sales@, noreply@), free mailbox (Gmail, Yahoo, Outlook), and a typo suggestion when the domain is one edit away from a major provider.

The output of those five is not "valid" or "invalid". It's:

Status	Meaning	What to do
deliverable	Domain resolves, has an MX, not disposable, syntax clean	Send
risky	Reachable but flagged — disposable domain, or no MX record	Decide by campaign
undeliverable	Domain doesn't exist, or syntax is invalid	Drop

Role and free-mailbox are flags, not statuses. support@apify.com is deliverable and a role address; whether that disqualifies it depends entirely on what you're sending. The status says whether mail can arrive. The flags say whether you want it to.

The reason a missing MX lands in risky rather than undeliverable is a detail of the standard: with no MX record, a sending server falls back to the domain's A record and tries to deliver there (RFC 5321 §5.1). That almost always fails, because the machine behind the A record is a web server with no mail daemon — but "almost always" isn't "never", so the honest label is risky.

Real output

This is an actual run, not a mockup. Six addresses and four phone numbers went in on 4 September 2026; four of the email results:

[
  { "email": "support@apify.com",
    "emailStatus": "deliverable",
    "emailDomain": "apify.com", "emailIsRole": true,
    "emailIsFree": false, "emailIsDisposable": false,
    "contactScore": 45 },

  { "email": "fake@nonexistentdomain-xyz-99.com",
    "emailStatus": "undeliverable",
    "emailReason": "domain_not_found",
    "contactScore": 0 },

  { "email": "test@mailinator.com",
    "emailStatus": "risky",
    "emailReason": "disposable_domain",
    "emailIsDisposable": true,
    "contactScore": 15 },

  { "email": "noreply@gmial.com",
    "emailStatus": "risky",
    "emailReason": "disposable_domain",
    "emailIsRole": true, "emailIsDisposable": true,
    "contactScore": 15 }
]

That last one is the interesting case. gmial.com is a misspelling of gmail.com, it is registered, it resolves, and it sits on the public disposable-domain blocklists. A syntax check passes it. A domain-resolution check passes it. It takes the blocklist — or, independently, the missing MX record — to flag it, which is the argument for running all five checks rather than the one you think is decisive.

One more from that run, which I'll return to at the end: a live business domain that came back risky, reason no_mx_record. Working website, working DNS, no mail exchanger. Every email sent to that domain bounces, and its owner had no idea.

Phone numbers: the rules are published

North American phone validation has a real specification, which means real verification instead of a regex.

The North American Numbering Plan Administrator publishes the assignment file at reports.nanpa.com/public/npa_report.csv. It lists every area code, whether it's geographic, which state, province or territory it belongs to, and its time zone. In the file dated 3 September 2026 there are 378 geographic area codes in the United States, and 454 across the whole plan once Canada and the Caribbean members are counted.

From that file plus the plan's own rules:

The area code must be assigned and in service. 999 is not: it's one of 79 codes with a 9 in the middle that the file marks Expansion Code, held back for when the plan runs out of numbers. Every one of them fails.
Area code and exchange both start with 2 through 9, never 0 or 1.
The N11 codes are service codes — 911, 411, 211 and the rest — and are never assignable as exchanges. A handful more, 555, 950, 958, 959 and 976, are held back by convention rather than by rule.
Within 555, only the block 555-0100 to 555-0199 is formally set aside for fictional use. This is the part most validators get wrong in the other direction: 555-1212 is a live directory-assistance number, so "reject anything with 555" produces false negatives on real data. Reject the reserved block, not the exchange.

Real output from the same run:

[
  { "phone": "+1 415 555 0132",
    "phoneStatus": "invalid", "phoneReason": "reserved_exchange" },

  { "phone": "+1 999 123 4567",
    "phoneStatus": "invalid", "phoneReason": "nanp_rule" },

  { "phone": "+62 361 123456",
    "phoneStatus": "valid", "phoneType": "international",
    "phoneReason": "structure_only", "phoneE164": "+62361123456" }
]

Note the third one. 0361 is genuinely the Denpasar area code, so the number is correctly formed for Bali, and the honest answer is structure_only — the number is correctly formed, and outside the NANP there is no equivalent public assignment file to check it against. A tool that claims to "validate" any international number without saying that is telling you it checked something it didn't.

For valid North American numbers you also get the state and the time zone, which is what you actually wanted — a lead list sorted by local business hours. One gotcha worth hard-coding: Arizona does not observe daylight saving, so it needs America/Phoenix, not America/Denver, or half your calls land an hour off for eight months of the year.

Who needs this

Anyone buying or scraping lead lists. Bounce rate is what gets a sending domain blacklisted. The clearest published numbers come from Amazon SES: a hard-bounce rate at or above 5% puts an account under review, 10% suspends it. Most other providers publish nothing and act on their own thresholds, which is worse, not better — you find out by being throttled.

Sales teams paying per contact. Enrichment vendors charge whether the contact is alive or not. Filtering before import is cheaper than filtering after.

Anyone with a signup form. Blocking disposable domains at registration removes most throwaway accounts, and the typo suggestion recovers real users who would otherwise never receive the confirmation email.

CRM hygiene. Contact data goes stale continuously as people change jobs, companies fold and domains lapse. The often-quoted "22.5% a year" traces back to a single HubSpot blog post and shouldn't be treated as measured, but the direction isn't in doubt, and a quarterly pass over the whole database catches the decay before a campaign does.

Running it

The Email Verifier & Phone Number Validator actor does the checks above with no SMTP dependency, which is why it works from anywhere. It runs bulk email verification and phone number validation in the same pass, over a pasted list, a CSV, or another actor's dataset.

Input:

{
  "emails": ["support@apify.com", "test@mailinator.com"],
  "phones": ["+1 415 555 0132", "+1 212 555 0199"],
  "keep": "all"
}

From the API:

curl -X POST "https://api.apify.com/v2/acts/lergassy~email-phone-verifier/runs" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -d '{"emails":["support@apify.com"],"phones":["+1 415 555 0132"]}'

It also reads another actor's dataset directly, which is the part worth knowing. Point inputDatasetId at the output of any scraper that produced contacts and it verifies that dataset in place:

{
  "inputDatasetId": "abc123def456",
  "emailField": "email",
  "phoneField": "phone",
  "keep": "deliverable"
}

Set keep to deliverable and the output contains only contacts that passed. Scrape, verify, import, with nothing in between.

What it does not do

It does not confirm that a specific mailbox exists. Nothing that runs on ordinary cloud infrastructure can, for the port 25 reason above, and on catch-all domains nothing can regardless of where it runs.

It does not tell you whether a phone is mobile or landline. That requires a carrier lookup against paid HLR data, which is a different product at a different price.

It does not check whether a person still works somewhere. That's job-change data, sold by LinkedIn-adjacent vendors, and no amount of DNS will produce it.

What it does is remove the addresses that will definitely bounce and the numbers that cannot possibly ring, and label the rest with the reason. On the scraped lists I've run it through, that has been somewhere between a seventh and a third of the rows — and it's that fraction which costs you a sending domain.

The postscript

The domain that came back no_mx_record in the run above belongs to a real, working business. Its website loads, its DNS resolves, and mail was simply never configured.

A sender with no MX record to aim at falls back to the domain's A record and tries to deliver there. That machine is a web server which has never spoken SMTP, so the message fails — quietly, for as long as the domain has existed. Nobody at that company knew, because a bounce lands in the sender's inbox, not theirs.

There is a decent chance this is true of a domain you own. Run your own addresses through something before you run anyone else's.

Actor: Email Verifier & Phone Number Validator on Apify

Related: US New Business Leads delivers newly registered US companies with these same checks already applied to every phone and email in the feed.

Telegram Channel Analytics Without an API Key — Subscriber Counts Lie, Reach Doesn't

Nikita Iakovlev — Fri, 04 Sep 2026 06:33:13 +0000

A Telegram channel with 10.9 million subscribers and a channel with 172,000 subscribers. Which one would you advertise in?

Here are their actual numbers, from a run over the last 100 posts of each on 4 September 2026:

	Pavel Durov	Bloomberg
Subscribers	10,900,000	172,000
Median views per post	5,600,000	39,900
Reach	51.4%	23.2%
Reach trend	−10.4%	+44.9%
Reactions per post	1,030	144
Posts per day	0.3	0.2

Durov's channel reaches half its audience — extraordinary, and 140× more people in absolute terms. But its reach is falling, while Bloomberg's is up 45% over the same window. Depending on whether you're buying one placement or a six-month presence, those two facts point in different directions.

None of this is in the subscriber count, which is the only number most people look at. All of it is available without an API key.

The three ways into Telegram data, and why two of them don't work

Bot API. Requires your bot to be an administrator of the target channel. Perfect for channels you own, useless for every channel you don't.

MTProto / user API. Full access to everything a logged-in user sees. Requires a phone number, a 2FA session and careful rate limiting. Reading public channel history through it is relatively low-risk; bulk member-list exports and messaging strangers are what actually get accounts limited. Either way you are putting a real phone number behind the request, and a restriction lands on the number, not the IP.

The public preview page. Telegram serves t.me/s/<channel> to any visitor, no account required. It's the same HTML a search engine sees.

For monitoring channels you don't own, the third option is the only sane one. What it gives you:

Channel header: title, subscriber count, description, photo, verified badge, media counts
20 posts per request, paged backwards with ?before=<message_id>
Per post: message id, ISO timestamp, full text, view count, reactions with their emoji and counts, media flags, forward source, reply flag, author signature

About 1.4 seconds per page, so 200 posts — ten pages — in roughly fifteen seconds. No token, no proxy required, no ban risk.

Why views are the number that matters

Telegram is unusual in how far it goes here: every post in a public channel carries a view count, visible to anyone, with no login and no API. X and Instagram both surface view counts too, but only inside their own apps, behind authentication and rate limits — which is the difference that matters if you want to compute anything across a list of channels.

That single number lets you compute the thing advertisers actually price against:

reach = median views per post / subscribers

Median, never average. One viral post drags an average up by a factor of three and tells you nothing about what a normal post does. On the Durov channel the average is 6.66M against a 5.6M median, and the best post did 24.2M — if you quoted the average to a client you would be promising reach that a typical post won't deliver.

Reach separates real audiences from bought ones instantly. A channel with 200,000 subscribers and 4% reach was inflated. A channel with 50,000 subscribers and 40% reach is worth more per post than the inflated one, and usually costs less.

What else the timestamps give you

Once you have a few hundred posts with timestamps and view counts, several useful things fall out of simple arithmetic:

Reach trend. Median views of the newer half of the window against the older half. Bloomberg's +44.9% and Durov's −10.4% above come from exactly this. It's a direction, not a forecast, but it's the difference between buying into a channel on the way up and one on the way down.

Best hours and weekdays. Group posts by hour, take the median views of each group, and require at least two posts per group so a single outlier can't win. This is a channel's own data, which beats every generic "best time to post" article ever written, because those articles are about a different audience in a different time zone.

Cadence. Posts per day and per week. A channel posting fifty times a day burns its audience differently from one posting twice.

Content mix. Share of posts with photos, videos, polls, links. Share that are forwards, and which channels they're forwarded from — run that across twenty channels in one niche and you have a map of who feeds whom.

Reaction rate. Reactions per post as a share of median views. Rough, but it separates channels that are read from channels that are merely delivered.

The mistakes worth avoiding

I got most of these wrong before the data corrected me.

A slow channel's 100 posts can span a year. Bloomberg's channel above posts 0.2 times a day, so 100 posts covers well over a year. Any "per day" figure computed over that window is an average across seasons. Always publish the number of days the window covers alongside anything rated per day.

Hashtag extraction needs a letter. A naive #\w+ regex turns #036 from a price into a top hashtag. Require at least one letter in the match.

Reach above 100% is not a bug. Telegram counts a view once per user, including people who saw the post forwarded into another channel or opened it on the web. A post that travels beyond its channel can be seen by more people than the channel has subscribers.

Timestamps are UTC. Convert to the channel's own time zone before concluding anything about a morning slot.

Minimal implementation

The page is server-rendered HTML with stable class names:

import requests, re
from bs4 import BeautifulSoup

def channel_page(name, before=None):
    url = f"https://t.me/s/{name}" + (f"?before={before}" if before else "")
    html = requests.get(url, headers={"User-Agent": "Mozilla/5.0"}).text
    soup = BeautifulSoup(html, "html.parser")

    posts = []
    for m in soup.select(".tgme_widget_message_wrap"):
        views = m.select_one(".tgme_widget_message_views")
        time_el = m.select_one(".tgme_widget_message_date time")
        posts.append({
            "id": int(m.select_one("[data-post]")["data-post"].split("/")[1]),
            "date": time_el["datetime"] if time_el else None,
            "views": views.get_text(strip=True) if views else None,
        })
    return posts

Two things this snippet doesn't do, and you need both: view counts arrive as 53K and 1.4M, so they need parsing into integers before any arithmetic; and paging requires passing the lowest message id you've seen back as before, then stopping when a page returns nothing new.

The finished version

I packaged the whole thing — paging, the K/M parser, all the metrics above, error rows for channels that have no public page — as Telegram Channel Analytics.

{
  "channels": ["@durov", "@bloomberg"],
  "postsPerChannel": 100,
  "topPosts": 3
}

One row per channel, with a ready-made sentence at the end of it:

{
  "channel": "bloomberg",
  "subscribers": 172000,
  "postsAnalysed": 100,
  "daysCovered": 415.1,
  "viewsMedian": 39900,
  "engagementRate": 23.2,
  "viewsTrendPercent": 44.9,
  "reactionsPerPost": 143.9,
  "bestHours": [{"hour": 8, "posts": 5, "medianViews": 62300}],
  "summary": "Bloomberg has 172,000 subscribers, median post reaches 39,900 views (23.2% of the audience), posts 0.2 times a day, reach up 44.9% across the 100 posts analysed."
}

One naming wrinkle worth flagging: the field is called engagementRate, but it holds what this article calls reach — median views over subscribers. The reaction rate is a separate field.

Switch on includePosts and every post arrives as its own row too, with views, reach, reactions, media flags, hashtags and links.

What it can't do

Private channels and groups are invisible. No public page, no data. Those come back as an explicit error row with the reason, never as a silent zero. Reading private chats requires a real account and a session, which is a different product with different risks.

Subscriber history doesn't exist in the source. Telegram publishes the current count and nothing else. "How fast is this channel growing" can only be answered by running on a schedule and keeping the results — a daily run turns subscribers, viewsMedian and engagementRate into a time series. There is no way to recover last month's number today.

Comments aren't in the preview. Discussion-group replies live elsewhere.

Where this is worth the effort

Buying advertising is the obvious one: compare candidates on reach instead of subscribers and the shortlist reorders immediately.

Selling it is the mirror image. A channel owner quoting reach, reaction rate, cadence and best hours is quoting a media kit. Most don't, because nobody computes it for them.

And competitor tracking, which is the use that compounds: run the same twenty channels weekly, watch whose reach is climbing, then look at what they changed in the same window. The content mix and posting hours are right there in the same row.

Actor: apify.com/lergassy/telegram-channel-analytics

Hotel Review Data in 2026 — Why Agoda Gives You Two Datasets for the Price of One

Nikita Iakovlev — Fri, 04 Sep 2026 06:32:51 +0000

If you're collecting hotel review data, Agoda is the source most people skip and the one with the most on it. Not because it has more reviews than Booking.com, but because it carries both.

Agoda was bought in 2007 by priceline.com, the company that renamed itself Booking Holdings in 2018 and also owns Booking.com, Kayak and OpenTable. One consequence is visible on almost every hotel page: Agoda displays its own guest reviews and Booking.com's, served by separate review providers behind the same page.

A real example, pulled this month:

{
  "type": "hotel",
  "name": "The Magani Hotel And Spa",
  "hotelId": 335650,
  "agodaReviewCount": 1347,
  "bookingReviewCount": 1025
}

That's 2,372 reviews for one mid-sized Bali hotel as of 4 September 2026, from two review pools with different reviewer bases, reachable through one page.

Why hotel review data is harder than it looks

There is no public API. Agoda has an affiliate and partner program with data access for approved partners. For everyone else — an analyst, a hotel owner benchmarking competitors, a developer building a comparison tool — there's the website.

Review counts on the page don't match what the page shows. A hotel page displays a paginated slice of reviews. The provider structure isn't visible in the HTML — you have to know that provider 332 is Agoda's own pool and 3038 is Booking.com's, and request each separately, or you silently collect half the data and never know.

The interesting fields aren't in the review text. Rating and comment are the easy part. Traveler type, room type booked, length of stay and reviewer country are what make the data analysable, and they're attached to the review record rather than rendered as prose.

Prices and availability are dynamic; reviews are not. This is the part that makes reviews the more useful target. A scraped price is stale in an hour. A review stays true to what its author wrote, give or take the occasional edit or deletion, which means a review dataset compounds while a price dataset decays.

What a review record actually contains

Real output, one review, unedited:

{
  "type": "review",
  "hotelId": 335650,
  "hotelName": "The Magani Hotel And Spa",
  "source": "agoda",
  "reviewId": 1175631129,
  "rating": 8.4,
  "title": "Magani",
  "text": "Great location, lovely staff , great breakfast & comfy bed",
  "reviewDate": "September 03, 2026",
  "checkInDate": "August 2026",
  "reviewerName": "Natalie",
  "reviewerCountry": "au",
  "travelerType": "Couple",
  "roomType": "Deluxe Room Double Bed",
  "lengthOfStay": 1,
  "reviewProvider": "Agoda",
  "helpfulVotes": 0
}

Four fields there are worth more than the review text.

reviewerCountry turns a review set into a demand map. Which markets actually book this property, and how do their ratings differ? Australian and Chinese guests rate the same Bali hotel differently, consistently, and if you run a property you need to know in which direction.

travelerType — Couple, Solo, Family with young children, Business — segments the ratings. A hotel averaging 8.4 might be a 9.1 for couples and a 6.8 for families, and the average hides the entire problem.

roomType attributes complaints to inventory. If the 4-star average is being dragged down by one room category, that's an operational fix, not a marketing one.

lengthOfStay separates the one-night airport stopover from the week-long stay. They are different products reviewed on the same page.

checkInDate matters more than reviewDate: it tells you when the guest was actually there, which is what you need to correlate a rating drop with a renovation, a management change or a rainy season.

Who uses this

Hotel operators benchmarking competitors. Five properties in the same district, all their reviews for the last two years, segmented by traveler type. The gaps are specific and actionable in a way that a star rating never is.

Revenue managers. Rating movements lead pricing power. A property whose cleanliness sub-score has fallen half a point over two quarters will lose rate before it loses occupancy.

Investors and acquirers. Reviews are the only public operational data on a private hotel. Trajectory over three years, complaint themes, and whether ratings recovered after the last renovation.

Travel product builders. Aggregating reviews across sources for a comparison site, a recommendation engine, or a chatbot that answers "quiet hotel in Ubud, good for families" from evidence instead of marketing copy.

Sentiment and NLP work. Hotel reviews are unusually good training data: a numeric rating attached to free text, in dozens of languages, with structured metadata about who wrote it.

Running it

Agoda Reviews Scraper takes hotel page URLs and handles both review providers.

{
  "startUrls": [
    { "url": "https://www.agoda.com/the-magani-hotel-and-spa/hotel/bali-id.html" }
  ],
  "maxReviewsPerHotel": 500,
  "reviewsProvider": "all",
  "reviewsSort": "recent"
}

reviewsProvider accepts agoda, booking or all. Use all unless you specifically want one pool. Note that these are the two large providers, not the only ones — some properties also carry smaller pools from regional partners, which this run doesn't pull.

From the API:

curl -X POST "https://api.apify.com/v2/acts/lergassy~agoda-reviews-scraper/runs" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -d '{
    "startUrls": [{"url":"https://www.agoda.com/the-magani-hotel-and-spa/hotel/bali-id.html"}],
    "maxReviewsPerHotel": 200,
    "reviewsProvider": "all"
  }'

Output is one hotel row per property with both review counts, then one review row per review. Sort options are recent, highest rating and lowest rating — and lowest-first is usually the more useful run, because the complaints cluster and the praise doesn't.

What you don't get

No prices. Review extraction and price extraction are separate problems, because prices depend on dates, occupancy and currency. For dated hotel pricing with the rate for your own check-in and check-out, that's Trip.com Scraper.

No reviewer identity beyond a first name and country. That's all Agoda publishes, and it's the right amount.

Hotel replies are hit and miss. Agoda does publish management responses, but adoption varies wildly by property — some hotels answer nearly every review, plenty answer none. Don't build an analysis that assumes replies exist.

Review counts vary by provider availability. Some properties have a large Agoda pool and almost no Booking.com reviews, or the reverse. The hotel row reports both counts before any reviews are pulled, so you can check coverage before committing to a large run.

Build versus buy, honestly

The hard parts here aren't conceptually hard: find the hotel id from a URL slug, call the review endpoint per provider, page through, normalise dates. A competent developer does the first version in a day.

The cost is the second year. Hotel ids get reassigned, the provider list changes per property, date formats differ by locale, and the endpoint shape shifts without notice. It's not difficult work, it's unscheduled work, arriving on the day you need the data.

The actor is free to run while it's new — you pay Apify's platform usage and nothing per review — which makes the build-versus-buy arithmetic hard to argue with. Build it if hotel data is your product. Don't if hotel data is an input to your product.

Actor: apify.com/lergassy/agoda-reviews-scraper

Related: Trip.com Scraper for dated hotel prices and ratings, Google Flights Scraper for airfare on the same trip.

Google Flights Data Without an API — What You Can Actually Get in 2026

Nikita Iakovlev — Fri, 04 Sep 2026 06:32:43 +0000

Google Flights is the best flight search on the internet, and one of the few major Google products with no self-serve API attached to it. QPX Express, the public tier that used to do this, was withdrawn on 10 April 2018. The engine itself never went away — ITA's QPX Enterprise is still sold to airlines — but nothing replaced the tier a developer could just sign up for.

What's left is the page. It's worth more than people assume, because it carries something the airlines themselves don't publish.

Here is a real run, Bali to Singapore, departing 15 October 2026, pulled this month:

{
  "type": "search",
  "origin": "DPS",
  "destination": "SIN",
  "departureDate": "2026-10-15",
  "tripType": "one_way",
  "currency": "USD",
  "flightsFound": 164,
  "lowestPrice": 82,
  "priceLevel": "typical",
  "typicalPrice": 68,
  "typicalPriceLow": 55,
  "typicalPriceHigh": 110,
  "priceHistory": [
    {"date": "2026-07-05", "price": 54},
    {"date": "2026-07-06", "price": 58},
    {"date": "2026-07-07", "price": 58}
  ]
}

Look at priceLevel, typicalPrice and priceHistory. Google tracks what this route normally costs and tells you where today sits in that band. $82 against a typical $68, in a normal range of $55 to $110. It's "typical", not a deal.

No airline gives you that. No aggregator gives you that for free. It's the single most useful field on the page and it exists because Google has been recording every route's fares for years.

Why there's no API

The data isn't simply Google's to hand over. By QPX's own documentation the inputs are schedules from OAG, published fares from ATPCO, and availability supplied directly or indirectly by the carriers. Google can compute and display itineraries from those inputs. Reselling the underlying feeds is a different question with a different set of licensors.

The industry alternatives are expensive. Amadeus and Sabre sell developer access, with per-call pricing, contracts and certification. Duffel and Kiwi are friendlier but priced for booking flows, not research: they expect you to sell tickets, not analyse fares.

The page is a heavy client-side app. Google Flights renders results in the browser from an internal protocol buffer payload. There's no HTML table of flights to parse, which is why most naive attempts return an empty list and conclude the data isn't there.

Results are personalised and regional. Currency, available carriers and sometimes price depend on where the request comes from. A fare pulled from a US datacenter is not necessarily the fare a user in Jakarta sees, and if you're doing price comparison research that difference is your entire result.

What you get per flight

Each flight in the results is a full itinerary, not a price tag:

{
  "type": "flight",
  "price": 82,
  "isBestFlight": true,
  "airline": "Scoot",
  "flightNumbers": ["TR289"],
  "stops": 0,
  "departAirport": "DPS",
  "departAt": "2026-10-15T14:05",
  "arriveAirport": "SIN",
  "arriveAt": "2026-10-15T16:55",
  "totalDurationMinutes": 170,
  "duration": "2 hr 50 min",
  "legs": [
    {
      "flightNumber": "TR289",
      "airline": "Scoot",
      "airlineCode": "TR",
      "from": "DPS",
      "fromName": "I Gusti Ngurah Rai International Airport",
      "to": "SIN",
      "toName": "Singapore Changi Airport",
      "departAt": "2026-10-15T14:05",
      "arriveAt": "2026-10-15T16:55",
      "durationMinutes": 170
    }
  ]
}

Multi-leg itineraries come back with every leg, its operating carrier, and the layover between them — which matters, because a $40 saving that costs a nine-hour layover in Kuala Lumpur isn't a saving.

isBestFlight is Google's own flag combining price, duration and stops. Useful as a shortcut, and useful to ignore deliberately when you're studying what a route actually costs rather than what Google recommends.

What it's genuinely good for

Price monitoring on routes you care about. Run the same route daily, keep the results, and priceLevel plus your own history tells you when to buy. This is the use case that pays for itself in one trip.

Route research. Which carriers fly a city pair, how often, at what times. For anyone planning capacity, a travel business, or a relocation, that's a survey nobody publishes in one place.

Fare benchmarking for travel agencies. Comparing your GDS fare against the public best price on the same route, daily, tells you where your inventory is uncompetitive.

Seasonality studies. Run a route across a range of departure dates and the shape of the year appears — the shoulder seasons, the holiday spikes, the exact week a route gets expensive.

Visa and immigration paperwork. Several consulates want proof of onward travel. Knowing the real price band of the cheapest exit flight, for the right date, is the difference between a $60 ticket and a $300 one.

Running it

Google Flights Scraper takes IATA codes and dates:

{
  "origin": "DPS",
  "destination": "SIN",
  "departureDate": "2026-10-15",
  "adults": 1
}

Round trips take returnDate. Several routes in one run go in routes. Open-jaw and multi-city itineraries go in multiCityLegs. Cabin class, passenger mix and currency are all inputs.

From the API:

curl -X POST "https://api.apify.com/v2/acts/lergassy~google-flights-scraper/runs" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -d '{"origin":"DPS","destination":"SIN","departureDate":"2026-10-15","adults":1}'

Output is one search row per query — with the price band, the history and the totals — followed by one flight row per itinerary. The search row alone answers "is this cheap right now", which for monitoring is the only row you need to keep.

What you don't get

No booking. This is research data. Booking requires an airline or an OTA, and the fare you saw may be gone by the time you get there, which is normal for airline pricing rather than a defect in the data.

No seat availability or fare rules. Change fees, baggage allowance and refundability aren't on the results page. They live in the fare rules, which are a GDS product.

Prices are indicative. Google shows fares from its partners, and the same flight can be cheaper direct or on a regional OTA. Treat the number as a benchmark, not a quote.

Personalisation is real. If you need the fare a specific market sees, the request has to originate in that market. Comparing "the DPS–SIN price" across regions requires deciding which region you mean.

The honest build-versus-buy note

Parsing Google Flights is not a weekend project. The payload is a nested protocol buffer with no field names, positional rather than keyed, and the positions move when Google ships a change. Every published parser is a set of magic array indices that somebody re-derived by hand after the last break.

If flight data is your core product, you'll end up owning that maintenance regardless. If it's one input among many, someone else's parser is the right answer — this one is currently free to run, with only Apify's platform usage to pay — and the two hours you'd spend on the first version are better spent on what you do with the numbers.

Actor: apify.com/lergassy/google-flights-scraper

Related: Agoda Reviews Scraper and Trip.com Scraper for the hotel half of the same trip.