DEV Community: themineworks

Apify pay-per-event billing: four ways I charged users for nothing

themineworks — Mon, 31 Aug 2026 18:58:08 +0000

Apify pay-per-event billing: four ways I charged users for nothing

I run 51 scrapers on Apify behind seven MCP servers. Agents call them as tools
over the Model Context Protocol:
Claude asks for a company's SEC filings, or Reddit posts about a product, or
open roles at a competitor, and a tool call goes out and comes back with rows.

Before I shipped any of it I wrote down one rule. A tool call that returns
nothing must never fire a billable event.

It reads like a small rule. Under Apify pay-per-event billing it is the single
hardest thing I have had to enforce, and I got it wrong four separate times, in
four different ways, each one invisible from the outside. Every one of them was
caught by the same check, which I will get to at the end. If you are putting a
paid Actor behind an agent, this is the post I wanted to read first.

Prerequisites

None of this needs special tooling, but it assumes you are past these three
things:

An Apify account.
An Actor you have published with pay-per-event monetization enabled, and at least one billing event registered for it in Console.
Node with the apify-client package and an API token, so you can call that Actor from code rather than from the Console. Three of the four bugs below only appear when the caller is not a browser.

Why Apify pay-per-event billing breaks quietly with agents

A person who runs your Actor and gets nothing back looks at the empty dataset
and asks for a refund. That feedback loop is fast and it is loud.

An agent does not do that. It gets an empty result, says "I could not find
anything for that company," and moves on. The user never sees your Actor's
name. Nobody files a complaint. If you were charging for those calls, you would
find out from your revenue graph looking suspiciously good, which is not a
thing anyone investigates.

So the usual signal that tells you billing is broken does not arrive. You have
to go looking.

Failure one: the summary row

My scrapers append a bookkeeping row to the end of every dataset. Run stats,
counts, that kind of thing:

{ "_type": "summary", "posts_scraped": 0, "charged_for": 0 }

My billing wrapper decided "did this return anything?" by counting dataset
items. A search that found nothing still returned one item. One is more than
zero. The call billed.

Worse, one of my resolver Actors emits an explicit not-found row rather than
staying silent:

{ "resolved": false, "query": "asdfghjkl ltd" }

Same outcome. Gibberish in, a row out, a charge fired.

The fix is not complicated once you see it, but you have to see it:

const billable = items.filter(
  (i) => i._type !== 'summary' && i.resolved !== false
);
if (billable.length === 0) return { found: false, billed: null };

The general shape of the bug: raw item count is not the same as delivered
results. Any row your own pipeline adds for its own purposes will lie to a
naive counter.

Failure two: `Actor.charge` does not throw

This one cost real money and it is the one I would most want other people to
know about.

I shipped a new Indeed tool. The PPE event for it did not exist in Console yet,
because the browser tab died halfway through the pricing wizard and I did not
notice. The tool went live.

It worked. It hit Indeed, came back with ten real postings, and told the caller:

{ "billed": { "event": "search_jobs_indeed", "count": 1 } }

The platform recorded:

{ "chargedEventCounts": {} }

So it served real data, over residential proxy that we pay for by the gigabyte,
for free, while reporting that it had charged.
Actor.charge
does not throw when you hand it an event name that was never registered. It
returns. My billing code had no try/catch because there was nothing to catch.

The rule I now follow without exception: register the event in Console before
deploying any tool that references it. Not after, not in the same sitting,
before. When I caught this I pulled the tool out of the tools array and
redeployed within minutes, then put it back only once GET /v2/acts/{id}
showed the event in pricingInfos.

There is a hardening step I have not built yet and probably should: have the
server refuse to register a tool whose billing event is missing from the
Actor's own pricingInfos at startup. That turns a silent revenue leak into a
loud boot failure. Flagging it as a gap rather than pretending I solved it.

Failure three: `prefill` is not `default`

This one did not cost money. It quietly broke an Actor for every programmatic
caller for an unknown length of time, which is arguably worse.

My Google Trends Actor declared its proxy input like this:

{
  "proxyConfiguration": {
    "type": "object",
    "prefill": { "useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"] }
  }
}

prefill populates the form in the Console. That is all it does, and the
input schema specification
says so plainly once you go and read it. Open the Actor in a browser, the field
is filled in, you hit run, it works.

Call the same Actor from the API, or from a schedule, or from an MCP server,
and proxyConfiguration arrives as undefined. No residential proxy, against
an endpoint that returns 429 to datacenter IPs on sight.

Every human test passed. Every programmatic caller failed, including my own MCP
server calling my own Actor. The fix is a real default, plus a fallback in
code so the schema and the runtime cannot drift apart:

const proxy = input.proxyConfiguration ?? {
  useApifyProxy: true,
  apifyProxyGroups: ['RESIDENTIAL'],
};

I then swept all 96 Actors on the account for the same pattern. Sixteen had it.
Fifteen were harmless because the code already had a fallback. One was a live
gap on an Actor doing 146 runs a month. If you built your Actors by cloning a
template, and most of us did, go and check. It is a ten minute grep.

Failure four: a successful run that delivers nothing

Two of my Actors showed "17 of 17 runs succeeded" for weeks while returning
zero rows to everybody.

Not failing. Succeeding. The target had changed its markup, the parser matched
nothing, the Actor wrote its summary row and exited zero. Every dashboard was
green. The 30-day success rate on the Store listing said 100%.

Billing was correct throughout, nobody was charged, which is the only reason
this was not a refund event. But the listing was selling something that did not
work, and the stat I would have pointed at to prove it worked was the stat
hiding the problem.

Run status tells you your process exited cleanly. It tells you nothing about
whether a customer got data. They are different questions and only one of
them matters. I now alert on delivered rows per run, not on run status, and I
would treat any Actor reporting a suspiciously perfect success rate as unproven
rather than reliable.

The one check that catches Apify pay-per-event billing bugs

Every one of these was found the same way. After a call, compare what your own
code thinks it billed against what the platform actually recorded:

const run = await client.run(runId).get();   // NOT the runs-list endpoint
const platform = run.chargedEventCounts ?? {};
const mine = { [event]: 1 };

if (JSON.stringify(platform) !== JSON.stringify(mine)) {
  console.error('BILLING MISMATCH', { runId, mine, platform });
}

One detail that wasted an afternoon: GET /v2/acts/{id}/runs returns an
abbreviated record with chargedEventCounts: {} and pricingInfo: null even
when charges definitely exist. Only the
get-run endpoint,
GET /v2/actor-runs/{runId}, has the real numbers. Do not conclude "nothing
was charged" from the list endpoint. I did, twice.

That comparison is the only thing that detects this whole class of bug. Unit
tests will not, because your code is behaving exactly as written. Manual
Console testing will not, because the Console is the one caller that gets the
prefills. Watching your revenue will not, because the failure mode is revenue
that looks fine.

I now run it on every tool on every server as part of the release check. It has
caught something every single time I have added tools.

One more thing, if you are building for agents

Unrelated to billing but it will bite you in the same week:
Apify Standby
returns 504
on any response over five minutes, whatever timeout you set yourself.

I had a composite tool that chains an Amazon product search into a review pull.
Amazon runs 45 to 110 seconds for a search and about 107 for reviews, so I set
an internal budget of 420 seconds to be safe. The gateway killed it before my
own tool ever finished. 280 seconds fits and works.

If your Actor genuinely runs for 20 minutes, it cannot be a synchronous tool
call at all. It has to return a run ID immediately and let the agent collect the
result later. Worth designing for on day one rather than discovering at 420
seconds.

Conclusion: what I would tell someone starting

Write the invariant down before you write the billing code. Mine is one
sentence and it has paid for itself repeatedly, mostly by making it obvious
which of my assumptions were wrong.

Then assume you have broken it, and go and check against the platform's own
numbers rather than your own. Four for four, that is where I found it.

If you want to test your own Actor for this today, there are three things worth
doing in order. Call one tool you already ship with an input you know returns
nothing, then read the run back from the get-run endpoint and compare
chargedEventCounts against what your code says it billed. Grep your input
schemas for prefill on any field that the runtime actually depends on, and
give each one a real default. Then take any Actor sitting at a perfect 30-day
success rate and check its delivered rows per run, because that is the number
the success rate is hiding. Each one is a short job. All three found something
on my account.

Author bio

The Mine Works builds and maintains 82 web scrapers on the Apify Store, with
seven MCP servers over them so AI agents can call the data as tools. All of it
runs on Apify pay-per-event billing, which is why one rule sits above the rest:
a tool call that returns nothing must never fire a billable event. Most of what
gets published here is a record of how that rule got broken and what the fix
looked like, with the run counts and the failure modes left in rather than
tidied away.

How I check whether a research finding actually holds up

themineworks — Thu, 06 Aug 2026 07:35:00 +0000

Somebody sends you a study. It has a striking result, it is in a real journal,
and it is exactly what you wanted to hear. The question nobody asks before
repeating it is the one that matters: has anyone actually built on this, or has
it quietly failed to replicate while everyone kept citing the original?

You cannot tell that from the paper itself. A paper always sounds confident. What
tells you whether a finding held up is what happened after it, who cited it, and
whether the field moved forward on it or moved on from it. That is the citation
graph, and reading it by hand means opening a paper, opening every paper that
cites it, and reading those too. Nobody does this, which is why weak findings
travel so far.

What I actually did

There is a public record of which papers cite which, from OpenCitations. Here is
the call I run on a paper's DOI:

// tools/call → citation_graph
{ "dois": ["10.1038/nature12373"], "direction": "citations" }

That returned 20 citation records in a few seconds, each one a paper that built
on the original. The direction matters: "citations" gives you who cited this
paper, which is the forward trail, what happened after the claim. You can also
ask for references, the backward trail, what the claim was built on.

How to read it

Follow the forward trail. Pull the papers that cite the finding. If the
citing work is replicating, extending, or applying the result, the finding is
doing real work in the field. That is a good sign.
Watch for the citation that never moves. The warning sign is a finding
that gets cited constantly but always in the same shallow way, an
introduction line, never actually built on. When everyone is citing the same
original paper and nobody has reproduced it, that is a finding coasting on its
own reputation.
Check the backward trail on the claims you rely on. Ask for references to
see what a paper stands on. A striking result built on one thin source is a
different bet than one built on a decade of converging work.

Why this works

Science is supposed to be self-correcting, but the correction is buried in the
citation record, not stated anywhere. A paper will never tell you it failed to
replicate. The papers that came after it will, if you read who cited it and how.
Walking that graph is the actual work of checking a finding, and it is the part
everyone skips because it is tedious. Making it one call removes the excuse.

Honest limits

This is citation metadata, not the full text of every paper, so it tells you who
cited what, not the nuance of why. Citation coverage differs between databases
because their corpora differ. And a high citation count is not the same as a
replicated result, which is exactly the trap this helps you avoid rather than
one it falls into. You still have to read the important citing papers. The graph
tells you which ones those are.

The tool is the Academic Research MCP
from The Mine Works, on Apify with your own account. Every source here is a free
public API, so it is the cheapest server in the suite to run, and a DOI with no
citations returns empty and costs nothing.

Rent it long-term or list it on Airbnb? I stopped guessing and ran one call

themineworks — Wed, 05 Aug 2026 10:45:00 +0000

Anyone who has owned a property has had this argument with themselves. Do I take
the steady long-term tenant, or do I furnish it and put it on Airbnb for more per
night but more hassle and more empty nights? Most people decide it on a feeling,
or on one Airbnb listing they saw once, which is not data, it is an anecdote.

The honest version of this decision needs four numbers for the same area: what is
for sale, what recently sold, what long-term rents ask, and what short-term
rentals actually earn. Those normally live in four different tools. I put them in
one call.

What I actually did

// tools/call → market_report
{ "location": "Austin, TX" }

For Austin that came back in about 19 seconds with all four sides. The two
numbers I put next to each other were a recently sold 3 bed, 1,984 square feet at
a $648,000 estimate in ZIP 78739, and a downtown condo renting on the short-term
market at $808 for three nights, rated 4.97 across 387 reviews.

Those are different ZIPs and different property types, so it is not a direct
swap. But it is the exact comparison the decision requires, and having both sides
in the same object means the arithmetic is right there instead of scattered
across four tabs.

How to actually decide with it

Pull the four sides for your specific area. Not a national average, your
ZIP. Real estate is local and averages lie.
Anchor on the sold price, not the asking price. What is listed is a hope.
What sold is what the market paid. Your yield math has to start from the real
number.
Read the review count on the short-term side, not just the nightly rate.
A high nightly price on an empty calendar earns nothing. 387 reviews at 4.97
is a property that is genuinely getting booked, which is a completely
different thing from one that is merely listed at a high price.
Do the yield both ways. Long-term rent times twelve, against nightly rate
times realistic occupancy. Now you are deciding on two numbers you trust
instead of a feeling.

Why this works

The reason people get this wrong is that the four data points live in four
places, so nobody assembles all four before deciding. They look at one Airbnb
listing, get excited by the nightly number, and forget that empty nights and
cleaning turn it into a job. Seeing supply, sold comps, long-term rent and real
short-term performance together is what turns a hunch into a decision.

Honest limits

Coverage is US only. The sold estimates are model output, not appraisals, and
they come back labelled as such. A thin market returns fewer records. The
short-term side reflects what is listed publicly, so it is a supply and pricing
picture, not a landlord's actual tax return. But for making the rent-versus-list
call with real numbers instead of a story, it is the fastest honest look I have
found.

The tool is the Real Estate MCP
from The Mine Works, on Apify with your own account. It bills by outcome, so a
location with no listings returns an empty report and costs nothing.

How I stopped my cold emails from bouncing and wrecking my domain

themineworks — Tue, 04 Aug 2026 05:05:00 +0000

The first cold campaign I ever sent tanked my domain. I had a list of names and I
had guessed the emails with the usual first.last@company.com pattern. A third of
them bounced, the mail provider noticed, and suddenly even my normal email was
landing in spam. It took weeks to recover the sending reputation.

The lesson is that a bounce is not a small miss. Every dead address you email
teaches the mail providers that you are a spammer, and they treat your whole
domain accordingly. So the real skill in cold outreach is not writing, it is
making sure every address you send to is actually alive before you send.

The mistake everyone makes

People verify their list at the end, if at all, as a separate cleanup step. By
then the guessed addresses are already baked in. The fix is to make discovery and
verification the same step, so the list you export has already been checked.

Here is the call I run on a company now:

// tools/call → prospect_dossier
{ "company": "Notion", "domain": "notion.so" }

It finds the people, pulls contact channels off the company's own site, and then
does the thing that matters: it runs a live check on every email it found,
chained onto the discovery. The verification is not against a list I typed. It is
against whatever the discovery just surfaced, so by the time I read the output,
every address has already been tested.

Read the verdicts honestly

The check returns a verdict per address, and the useful part is that it does not
round everything up to "valid." In my runs it returned invalid for a dead
address, risky for a role mailbox, and unknown for one behind a catch-all
server.

That unknown is the one to understand. A catch-all server accepts every
address you throw at it and tells you nothing, so any tool that reports catch-alls
as valid is inventing a number to make its accuracy look good. Honest is
unknown, and knowing an address is unknowable is itself worth having, because
you send to it at your own risk rather than blind.

The steps

Discover and verify in one call. Do not treat verification as a later
cleanup. Chain it, so nothing enters your list unchecked.
Drop everything marked invalid. These are the ones that bounce. Removing
them is the single action that protects your domain.
Decide on risky and unknown deliberately. Role mailboxes and catch-alls
are judgement calls, not automatic sends. At least now you are making the
call with eyes open.

Why this works

An invalid verdict is a real result, and worth paying for, because knowing an
address is dead before you send is exactly what saves your domain. The only
thing you should not pay for is a guess dressed up as a fact, which is what a
pattern-generated list is.

Honest limits

Verification cannot see past a catch-all server, and it says unknown rather
than pretending. Discovery quality depends on how much a company publishes about
itself, so pass a domain rather than a bare name, it materially improves the
result. This is public data for outreach, nothing from a private database.

The tool is the Lead Generation MCP
from The Mine Works, on Apify with your own account. It bills per result, and a
company where it finds nothing costs nothing.

The Reddit thread that warned me about a product before the numbers did

themineworks — Mon, 03 Aug 2026 08:50:00 +0000

Dashboards are always late. By the time churn shows up in a chart, the decision
that caused it was made weeks ago, by users who had already made up their minds
and were talking about it somewhere you were not looking. I got tired of finding
out about problems after they were expensive, so I started reading the places
people actually complain, on a schedule.

The insight is simple. A sentiment score going down tells you something is wrong.
It does not tell you what, and by the time you go find out, the thread has 300
comments. The actual complaint, in the user's own words, is worth more than any
score, and it shows up days before the metric moves.

What I actually did

I run one call that pulls a topic across Reddit, Threads, LinkedIn, news, X and
Google Trends at once:

// tools/call → brand_pulse_report
{ "topic": "Notion" }

On the run I am describing, four of the six sources returned and two came back
empty, so it billed the partial price and told me which two were empty rather
than quietly dropping them. The Reddit section is what I read first, and the top
thread was titled "How Notion is losing its credibility with the Notion AI
pricing mess."

That sentence is the whole point. It is specific, it has a cause, and it was
written by someone who cared enough to post it. No dashboard produces that.

How I turn it into an early warning

Pick the topic. Your product, a competitor, or a category. Whatever you
need to not be surprised about.
Run it daily and read the top threads, not the counts. The number of
posts is noise. The content of the loudest thread is the signal. You are
looking for a specific complaint that keeps recurring.
Watch for a complaint that gains traction. One angry post is nothing.
The same complaint, phrased slightly differently, showing up across Reddit
and Threads and LinkedIn in the same week, is a churn driver forming in
public, and you are reading it while there is still time to respond.

Why this works

People do not fill out your exit survey. They post on Reddit. The most honest
feedback about any product is written by users with no reason to be polite, in
places the company is not officially watching. Getting those posts into a tool
you can read every morning means you find the problem while it is still a
thread, not after it is a trend in your revenue.

The same call points at a competitor works in reverse. Their unhappy users are
describing, for free, exactly the thing you should build.

Honest limits

This reads public posts only. No private groups, no DMs. On the run above, X and
Google Trends came back empty, which happens, and the tool says so rather than
pretending otherwise. And it hands you the posts rather than a sentiment score
on purpose, because your own reading of a real complaint beats a lexicon
counting positive and negative words.

The tool is the Social & Market Research MCP
from The Mine Works, on Apify with your own account. It bills only for the
sources that return, so a quiet topic costs almost nothing and an empty one
costs nothing at all.

How I check out a company in the time it takes to make coffee

themineworks — Sun, 02 Aug 2026 06:10:00 +0000

I got burned once by a vendor that looked fine on the website and turned out to
be in the middle of a lawsuit and registered in a completely different name than
the one on the contract. After that I started checking companies before I signed
anything or got on a first call. The problem was doing it properly takes an hour
of opening the same six websites, so I mostly skipped it, which is exactly how
you get burned again.

Then I collapsed the whole check into one call, and now I run it on everyone.

What the check actually covers

Proper due diligence means the legal entity (is this a real registered company,
and which one), the filings, any litigation, whether they take government money,
and their reputation. Those live on SEC EDGAR, the GLEIF registry, state business
registries, CourtListener and USAspending. Five sites, five different search
boxes.

Here is the single call I run instead:

// tools/call → full_diligence_report
{ "company_name": "Palantir Technologies", "ticker": "PLTR" }

For Palantir that came back in about 50 seconds. The part that stopped me was the
entity section: alongside the US parent it returned the India subsidiary,
Palantir Shakti Technologies. Nobody types that name into a search box, because
nobody knows it exists. It shows up because the legal-entity lookup returns the
whole corporate family from the one name you asked about.

The rest came with it: the SEC identity (CIK 0001321655), the ten most recent
filings, ten court cases including one at the Delaware Supreme Court, and ten
federal contracts topped by a single Army task order worth $442,883,216.67.

How I use it

Run it on the name before the first call. By the time I am on the call I
know their real corporate structure, whether they are in litigation, and how
much of their revenue is government contracts. That changes what questions I
ask.
Read the court and contract sections first. Those are the two that
actually change a decision and the two that take longest to find by hand. A
company with heavy government revenue concentration is a different risk than
one without, and you want to know that before you are dependent on them.
Watch the entity section for surprises. Subsidiaries, a registered agent
that does not match, a formation state that makes no sense. The structure
tells you things the marketing site never will.

Why this works

Every piece of this is a public record that a company is required to file. The
information was always there. The only thing stopping people from using it is
that it is spread across five government databases with bad search. Put them
behind one call and a proper check costs less than the coffee you make while it
runs.

Honest limits

It reads public records, so it is only as good as the public record. A private
company in a state with thin disclosure returns less than a public one. The
court search covers US federal and state opinions in CourtListener, not every
county filing. If the answer is not in a public database, it tells you it found
nothing rather than guessing, which is the point.

The tool is the Company Diligence MCP
from The Mine Works, on Apify with your own account. It bills only when a section
returns something, so a clean company with no litigation costs nothing for the
empty court check.

How I see every ad my competitor is running, without any inside access

themineworks — Sat, 01 Aug 2026 03:44:00 +0000

For a long time I assumed knowing what a competitor was advertising required
some tool I could not afford, or a friend on the inside. It turns out the whole
thing is public, and most people never look because they do not know where.

Meta runs an Ad Library. By law, every ad running on Facebook and Instagram is
listed there, searchable by brand, with the creative, the format, and the dates
it has been live. It is open to anyone. The catch is the interface is slow and
built for one-ad-at-a-time browsing, so nobody uses it for real analysis. I wired
it to pull the whole picture in one call.

What I actually did

Here is the call I run against a competitor's name:

// tools/call → competitor_ads
{ "search_terms": ["Nike"], "country": "US", "status": "all" }

For Nike that came back in about ten seconds with live ads, including a
Spanish-language birthday promotion running across Facebook, Instagram, Audience
Network and Messenger. Each ad comes back with its creative text, its media type,
the advertiser page, and the dates it has been running.

That last field is the one that matters, and I will explain why.

The step that turns ads into intelligence

Pull all active ads for the competitor. You now have their entire live
creative in front of you, not a guess.
Sort by how long each ad has been running. This is the tell. A brand
kills ads that do not perform, fast, because they cost money every day. So an
ad that has been live for four months is not luck. It is their best
performer, the one they have tested against everything else and kept.
Read the long-runners, ignore the rest. The ad that has survived since
March is telling you which message, which offer, and which audience is
working for them right now. You just got their best-tested marketing angle
for free.
Watch for new entrants. Run it weekly. A brand-new ad that suddenly gets
heavy placement is a launch or a new campaign. You are seeing it on day one.

Why this works

Advertisers pay by the day. That single fact makes their spending honest in a
way their marketing never is. They will tell you anything in a press release,
but they will not pay to keep running an ad that does not sell. Duration is a
vote they place with real money, every day, and it is all public record.

You are not spying. You are reading a disclosure they are legally required to
make, in a format they hoped was too tedious to use.

Honest limits

This is Meta only, so Facebook, Instagram and their network. It does not cover
Google, TikTok or other channels. And you see the creative and the run dates,
not the spend amount or the exact audience, unless the ad is political. But for
figuring out what message a competitor believes in enough to keep paying for,
duration is most of the answer.

The tool is the E-commerce Intelligence MCP
from The Mine Works, running on Apify with your own account. It bills per ad
returned, so a competitor sweep costs a few cents and a name with no ads costs
nothing.

How I started finding jobs a week before they hit LinkedIn

themineworks — Fri, 31 Jul 2026 11:47:25 +0000

I spent a job search refreshing LinkedIn like everyone else, and I kept noticing
the same thing: by the time a role showed up in my feed, it already had 200
applicants. The good ones were closing before I finished the cover letter.

Then a recruiter friend told me something that changed how I looked for work.
Companies do not post to LinkedIn first. They post to their own applicant
tracking system first, the Greenhouse or Lever or Workday page that runs their
careers site. The job boards scrape those pages later. Sometimes days later.
So the freshest possible version of a job is the one sitting on the company's
own ATS, before any aggregator has touched it.

The problem is you would have to check dozens of career pages by hand every
morning. I did not want to do that. So I wired it up to check for me.

What I actually did

I use a small MCP tool that reads ATS boards directly. Here is the exact call I
run against a list of companies I want to work for:

// tools/call → search_jobs_ats
{ "companies": ["stripe"], "location": "Remote" }

For Stripe that came back in a few seconds with live postings straight off their
ATS, including "Account Executive, AI Sales (Grower)" in San Francisco, before I
had seen it anywhere else. The output is structured: title, team, location, and
the direct apply link. No scrolling, no login, no feed algorithm deciding what I
get to see.

The three steps

Make your target list. Pick 15 to 30 companies you would actually take a
job at. Their names or ATS slugs are all you need.
Run the pull once. One call returns every open role across those
companies. Read it like a table. I filter for my title and my location and
ignore the rest.
Put it on a schedule. This is the part that matters. I run the same call
every morning at 7am and diff it against yesterday. A new row means a role
that went live in the last 24 hours, usually before it reached the boards.
That is the window where you are applicant number 3, not number 300.

Why this works

An ATS is the source. Everything else is a copy. A role that closed yesterday is
already gone from the company's ATS but still sitting stale on three job boards,
which is why board listings waste your time. Run it the other way and the same
fact helps you: the newest thing on the ATS is the newest thing that exists.

The boards are optimised for their traffic, not your timing. Reading the source
directly is the whole hack.

Honest limits

This only covers companies whose ATS I can read (Greenhouse, Lever, Workday,
Ashby). A company on a different system returns nothing. And "before LinkedIn"
is often hours, sometimes a day or two, not always a week. But being early by
even a day on a role you want is the difference that gets you the first
screen.

The tool is the Recruiting & Jobs MCP
from The Mine Works. It runs on Apify with your own account, and it bills per
result, so a morning check on 20 companies costs a few cents and a search that
finds nothing new costs nothing.

DEV Community: themineworks

Apify pay-per-event billing: four ways I charged users for nothing

Apify pay-per-event billing: four ways I charged users for nothing

Prerequisites

Why Apify pay-per-event billing breaks quietly with agents

Failure one: the summary row

Failure two: Actor.charge does not throw

Failure three: prefill is not default

Failure four: a successful run that delivers nothing

The one check that catches Apify pay-per-event billing bugs

One more thing, if you are building for agents

Conclusion: what I would tell someone starting

Author bio

How I check whether a research finding actually holds up

What I actually did

How to read it

Why this works

Honest limits

Rent it long-term or list it on Airbnb? I stopped guessing and ran one call

What I actually did

How to actually decide with it

Why this works

Honest limits

How I stopped my cold emails from bouncing and wrecking my domain

The mistake everyone makes

Read the verdicts honestly

The steps

Why this works

Honest limits

The Reddit thread that warned me about a product before the numbers did

What I actually did

How I turn it into an early warning

Why this works

Honest limits

How I check out a company in the time it takes to make coffee

What the check actually covers

How I use it

Why this works

Honest limits

How I see every ad my competitor is running, without any inside access

What I actually did

The step that turns ads into intelligence

Why this works

Honest limits

How I started finding jobs a week before they hit LinkedIn

What I actually did

The three steps

Why this works

Honest limits

Failure two: `Actor.charge` does not throw

Failure three: `prefill` is not `default`