Home/Docs

Documentation

ApifyHub does two things: it turns the public Apify Store into numbers you can act on, and — once you have shipped something — it reports on your own actors run by run. The first half needs no account. This page covers both.

What ApifyHub is

ApifyHub has two parts. One is research on the public Apify Store, which anyone can use. The other is analytics on the actors you have published, which needs an SDK in your actor.

The Store side. The Apify Store shows you a list of actors. ApifyHub indexes that list and keeps the history: total runs, monthly users, pricing model and estimated creator revenue for every public actor, tracked week over week. That becomes a leaderboard of what actually earns, a trending feed of new releases gaining users, a search that puts revenue estimates next to results, creator profiles, monthly snapshots, and a set of tools for picking and positioning what to build next. None of it needs an account or an SDK — it is public data, organised.

Your side. Apify tells you what your actors earned in total. It does not tell you which actor, which customer, which day, or what the run cost you to produce. Two SDKs fill that in: @apifyhub/analytics reports each run — when it started and finished, whether it succeeded, how many results it pushed, what it charged and what it spent — and @apifyhub/sentinel reports crashes, grouped into issues with the stack trace and the input that caused them. They share one key and take about two minutes each.

Neither half replaces the Apify Console. They sit next to it and answer the questions it does not: which niche is underserved, which of your thirty actors is actually profitable, which customer is most of your revenue, and which run broke at 3am.

The two halves do not share data. What your actors report is private to your dashboard and is never used to build the Store research above — see Privacy.

Researching the Store

Free, public, and needing nothing of your own — this is the half of ApifyHub you can use before you have written an actor.

Every public actor on the Store is indexed with its total runs, monthly active users, pricing model and an estimate of what its creator earns, resampled so the history is there to compare against. Those numbers are what the pages below are built from.

  • Leaderboard — Actors ranked by estimated creator revenue, runs or monthly users, with week-on-week movement. There is a creators board too, for who is building the most valuable portfolios.
  • Trending — New releases picking up users, before they are obvious.
  • Search — Live Store search, with revenue estimates next to the results for the actors we have indexed.
  • Tools — The Actor count tracker (how big the Store is today, sampled daily, with its full growth curve), the SEO preview (what your listing looks like in Google, and what gets truncated), and the pricing calculator (converting between bundle and per-result pricing).
  • Guides — Copy-pasteable recipes for building actors, in JavaScript and Python: proxies, scheduling, webhooks, free-tier limits, detecting paying users, writing a listing that converts.

Signed in, these same pages live under /dashboard inside the app shell, so Store research and your own numbers sit one click apart.

Quick start

Everything from here needs an account: this is where you wire your own actors up. About two minutes each, and the key is per account rather than per actor, so you only do step 1 once.

  1. Generate your ApifyHub key. On your dashboard, or under Settings. It is shown once — copy it then.
  2. Add it to your actor as a secret environment variable named APIFYHUB_KEY (Apify Console → your actor → Settings → Environment variables). To keep it in the repo instead, put "environmentVariables": { "APIFYHUB_KEY": "@apifyhubKey" } in .actor/actor.json so it deploys with the actor.
  3. Install the SDK and wrap your actor — see below.
  4. Deploy. The next run shows up on the dashboard within seconds of finishing.

Adding a second actor later? The dashboard keeps the instructions behind a Setup instructions link in its header, with your existing key already filled in.

Analytics SDK

Wrap your actor body once. The wrapper passes through your return value and re-throws any error, so adding it cannot change how the actor behaves.

// npm install @apifyhub/analytics
import { withAnalytics } from '@apifyhub/analytics';

await withAnalytics(
  { apifyHubKey: process.env.APIFYHUB_KEY },
  async () => {
    // your actor code runs here as normal.
  },
);

If you cannot wrap the body — an actor whose entry point you do not control, say — JavaScript also exposes instrument(), which hooks the process and reports on exit. Prefer withAnalytics when you can: it knows exactly when the run ended and why.

Tracking cost

Revenue on its own is not a margin. If your actor spends money during a run — LLM calls, a paid proxy, any third-party API — report it and the dashboard can show profit instead of turnover.

Call trackCost(source, amountUsd) as many times as you like during a run. Totals per source accumulate in-process and ride along on the end-of-run beacon, so there is no extra network call and no per-call overhead.

import { withAnalytics, trackCost } from '@apifyhub/analytics';

await withAnalytics({ apifyHubKey: process.env.APIFYHUB_KEY }, async () => {
  const completion = await openai.chat.completions.create({ /* … */ });
  trackCost('openai', 0.0032);

  const page = await fetchViaProxy(url);
  trackCost('proxy', 0.0008);
});

trackCost never throws. A bad amountUsdis dropped rather than corrupting the run's totals or crashing your actor, and costs tracked before the SDK initialises are simply never sent.

The source string is yours to choose and becomes a row on Cost. Keep it stable and coarse — openai, proxy, scrapecreators — rather than one source per model or endpoint, or the breakdown turns into a long tail nobody reads.

Apify's own platform usage is folded in separately, from the run's reported usage, so you do not track compute yourself. Note that Apify only bills actor authors for usage generated by paying customers — free-tier runs cost you nothing and are excluded from the platform side of the total.

Sentinel SDK

Crash reporting for actors. Same key, separate package, same one-line wrap.

// npm install @apifyhub/sentinel
import { withSentinel } from '@apifyhub/sentinel';

await withSentinel({ apifyHubKey: process.env.APIFYHUB_KEY }, async () => {
  // your actor code runs here as normal.
});

For finer control there is init(), captureException(err), addBreadcrumb() and flush(). Exceptions are grouped into issues by fingerprint, so a hundred runs failing the same way is one issue with a count, not a hundred alerts. Each issue carries the stack trace with source context, the input the run started with, the breadcrumbs from the seconds before the throw, and the Apify run context — actor, build, run id, origin and which customer was running it.

Setup instructions live on the Sentinel page; there is also a live demo if you want to see it populated before wiring anything up.

Your dashboard

Every page below reads the same run data over the same date range — the range picker in the header is shared, and so are the filter chips.

  • Analytics — The overview. Runs, revenue, results and cost over time, with per-actor and per-customer breakdowns. Click any chip — a source, an actor, a customer — to scope the whole page to it.
  • Source — Where runs are started from — the Console, the API, a schedule, an MCP client, the Store's Test tab — charted over time. Useful for spotting a schedule that quietly stopped firing, or an integration ramping up.
  • Cost — Apify platform usage by category and by actor, plus every trackCost() source ranked by spend.
  • Margin — Every actor, worst margin first. The page to open when revenue is up and the bank balance is not.
  • Memory — Memory allocated versus memory actually used, per actor. Apify bills on what you allocate, so over-allocation is a direct, recoverable cost.
  • Sentinel — Crashes grouped into issues, with the stack trace, the input and the breadcrumbs.
  • Run rules — Server-side limits for free users of your actors: rolling windows, lifetime caps, cooldowns, and an allow/blocklist. Paying customers and Store test runs are never limited.

Plans and limits

Billing counts tracked events — one event is one run reported by the SDK.

  • Free — a lifetime allowance of 10,000 events. We keep ingesting past it, so nothing is lost, but the dashboard freezes at the data from those first 10,000 events until you upgrade.
  • Paid — 100,000 events included each calendar month, then $5 per additional 100,000, billed in whole blocks so invoices stay round. There is a warning band above the included quota before anything bills.

Your usage for the current period, and the month-by-month history, are on Settings → Usage. Full plan details are on the pricing page.

Privacy

Your analytics are yours. They are not an input to anything else we build.

Nothing the SDK reports is used anywhere outside your own dashboard. Not in the leaderboard, not in trending, not in the revenue estimates, not in search, not in any ranking or benchmark, and not in aggregate. The Store side of ApifyHub is built purely from the public Apify Store — the same pages and API anyone can read — and it never touches the run data your actors report. The two halves share an account and nothing else.

So your revenue, your customers, your costs and your margins are visible to you, and to nobody else. Being on ApifyHub does not put your actor's real numbers into anyone's ranking; the estimate the leaderboard shows for your actor is computed from public figures exactly as it is for every other actor, whether or not you have ever installed the SDK.

What the SDK sends. Per run: the actor id and build, the run id and its origin, start and end time, exit status, how many results were pushed and how many events were charged, the revenue Apify recorded, an anonymised identifier for the customer whose account the run billed to, whatever you reported via trackCost(), and the run's resource stats.

What it does not. Your dataset contents are never read or transmitted — the SDK reports on the run, not on what the run scraped. It never asks for your Apify API token either.

Sentinel additionally sends the exception, its stack trace with surrounding source lines, and the run's input. If your actor takes credentials as input, treat that the way you would any crash reporter and keep secrets in environment variables rather than in the input schema.

The privacy policy is the full statement.

Something missing here?

Mail support@mail.apifyhub.com and we will add it.