Apify

Marketplace + runtime for Actors — Dockerized API/scraper jobs that customers run on-demand or on schedule. Acts as billing + discovery + compute hosting in one. The 2026-preferred primary channel for the mini-apps/overview|mini-apps series given its mature CI, 80% provider revenue share, and clean pay-per-event pricing model.

Where rapidapi is “they front-door your API,” Apify is “they host your code (or your wrapper) and meter it for you.” Critical structural difference downstream.

What Apify handles for you

Concern	What Apify does
Billing	Per-event metering, monthly invoicing, payout
Compute hosting	Runs your Dockerized Actor on their infra
Customer auth	API tokens issued by Apify; you don’t manage users
Discovery	Apify Store with search + categories + ratings
MCP integration	Actors auto-exposed via Apify’s MCP server — agent customers reach them for free
Docs hosting	Auto-generated from .actor/actor.json + input schema
HTTPS termination + scaling	Free at Actor runtime
Anti-detection / proxy network	Bundled — usable from inside Actor for scraping

What you keep:

• The Actor code (typically a thin wrapper around your real API)
• Pricing decisions (you set PPE rates per event type)
• The right to also self-host the same product

The Actor model

An Actor is a Dockerized job runnable via Apify’s API/SDK. You can host the compute on Apify OR proxy to your own infra (the url-intel/overview pattern — Coolify-hosted Go API wrapped as a thin Node Actor).

.actor/
├── actor.json        — id, version, dockerfile, input schema, categories
├── input_schema.json — JSON Schema for customer-supplied inputs
└── Dockerfile        — runtime image (Node, Python, Go all supported)
src/
└── main.js           — reads input → calls your API → pushes to Dataset → charges events
README.md             — the SEO surface for Apify Store

Minimum .actor/actor.json:

{
  "actorSpecification": 1,
  "name": "url-intel",
  "version": "0.1",
  "title": "URL Intel — Metadata, Screenshot, PDF",
  "dockerfile": "./Dockerfile",
  "input": "./input_schema.json",
  "readme": "./README.md",
  "categories": ["DEVELOPER_TOOLS"]
}

Apify CLI (the canonical publish path)

npm i -g apify-cli
apify login            # writes ~/.apify/auth.json; in CI use APIFY_TOKEN env var
apify create my-actor  # scaffolds from template
apify run              # local test, simulates platform env
apify push             # uploads + builds on platform (first push creates the Actor)
apify call <user>/<actor> --input-file test.json
# publish + pricing happens in Console UI under Publication tab — not via CLI

Pricing models (mid-2026)

Model	When	Provider share
Pay-per-event (PPE)	Default for utility/API-shaped Actors. Charge per result, per page, per token, etc.	80% of revenue minus platform costs
Pay-per-usage	Customer pays Apify’s compute markup; you get nothing direct	—
Rental (flat monthly)	Being killed: no new rentals after April 1, 2026, full retirement October 1, 2026	80%

PPE Actors get bonus visibility in the Store + are MCP-compatible (the agent-customer pipeline). Use PPE unless you have a specific reason not to.

Common PPE pricing for utility Actors (verified from top performers):

Pattern	Typical price
Actor start (synthetic event, first 5s compute covered by Apify)	$0 - $0.0001
Per result / per page	$0.0005 - $0.002
Per AI-extracted page	$0.002 - $0.005

Headline format: "$X/1k results" in the Actor title (not just description) — universal across top performers.

Revenue share, with the gotcha

Docs say profit = (0.8 × revenue) - platform costs. The platform costs are deducted from your 80%, not from Apify’s 20% — so a thin wrapper that underprices PPE relative to compute/egress can run negative. Always:

1. Estimate compute + egress per event
2. Price PPE at ≥ 3× that cost so 80% × revenue clearly covers it
3. Watch the dashboard early; tune up if margins erode

Auto-publish via CI

Mature pattern. One GitHub Action + one secret:

# .github/workflows/publish.yml
on: { release: { types: [published] } }   # gate on release tags, not every push
jobs:
  push-actor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: apify/push-actor-action@v1
        with:
          token: ${{ secrets.APIFY_TOKEN }}
          working-directory: apify/        # for monorepos

Alternative: set Actor source type to GIT_REPO in .actor/actor.json and Apify auto-builds on every push to the configured branch — even simpler than the GH Action.

”Proxy external API” pattern legitimacy

Apify docs explicitly reference “external APIs” as a cost driver in PPE pricing — they treat proxy-style Actors as legitimate. No anti-proxy clause exists. The MCP push (Apify exposing Actors via their MCP server) further encourages this pattern.

The risk surface is the Faulty Actor rule (Store T&Cs §8): if your upstream API breaks (your Hetzner box, your DNS, your dependency), the Actor fails. After 30 days unresponsive, Apify deprecates it. Mitigations:

1. Don’t ship pure pass-through — add input validation, retries with backoff, response normalization to Apify’s Dataset shape
2. Set up dead-man-switch monitoring on the upstream
3. Keep the Actor’s own logic minimal but its error handling rich

Listing automation: what’s scripted vs UI

• Creating + pushing + building: 100% scripted via CLI/API/Action
• Going public in Store: one-time UI step per Actor — title, description, categories, pricing tier setup. ~30 min in Console. No documented REST endpoint for the Publication tab as of 2026.
• Updates (apify push to existing Actor): instant, no review gate
• Time to first listing: minutes to hours after the UI step, not days

Where Apify wins vs rapidapi for url-intel

	Apify	RapidAPI
Provider share	80%	75% (Nov 2025 bump from 20% → 25%)
CI for auto-publish	Mature single-action pattern	Bare for public Hub — Enterprise-only actions
Provider sentiment 2025-2026	Positive, MCP push	”Honestly bad” — see rapidapi for the details
URL-intel category competitors	Apify-owned FREE rag-web-browser (rated 3.74 — room for paid alternative)	None — Microlink/Urlbox/ScreenshotOne all sell direct only
Pricing model fit	PPE matches usage pattern naturally	Tiered subscription forces customer to forecast usage

Apify is the strategic primary channel for project-url-intel|url-intel and successive mini-apps products. RapidAPI is “while-you’re-at-it” second channel — see reference-api-marketplaces in memory for the decision rationale.

Concrete pricing for url-intel on Apify

• Title: "URL Intel — $1.50/1k pages" (or "AI Page Reader — $2/1k" for the AI-positioned listing)
• Synthetic apify-actor-start event: $0.0001
• Per metadata extract: $0.0005 (~$0.50/1k)
• Per AI-cleaned extract (?ai=1): $0.002 (~$2/1k)

Where this fits in kulify

• url-intel/overview — first kulify product to be wrapped as an Actor
• Future mini-apps/overview|mini-apps products in Lane A — same Actor wrapper template; ~30 min per new listing once template is solid
• Demand-radar bets (Lane B) — Apify Store is search-discovery-driven, so trend-radar-sourced products benefit from the auto-traffic of Apify’s category pages and MCP exposure

Explicitly not the right fit for: fajb-next (B2B contracts), katastar (regulated + government), hegnar-web (FA’s own platform), manzas (B2B with dashboards) — those need direct sales infrastructure, same as the rule for rapidapi.

Related

• rapidapi — comparison + secondary channel
• marketplace-distribution — the abstract “marketplace handles billing” pattern
• url-intel/overview — first Actor target for the series
• mini-apps/overview — umbrella program where Apify is primary channel
• Model Context Protocol — Apify’s MCP server makes Actors discoverable by agent customers without separate listing work