DEV Community: Tim Zinin

How to Scrape PropertyFinder.ae Listings in the Gulf Without a Paid API

Tim Zinin — Fri, 02 Oct 2026 10:25:03 +0000

The problem

Gulf property data is a licensing problem before it is a technical one. Listings live behind portals like PropertyFinder.ae, and the organizations that legitimately hold the data — licensed data providers, brokerages with active mandates, owners, property managers — receive it as exports, not APIs. Before those records can enter a CRM, a warehouse, or a review queue, someone has to normalize the fields, deduplicate them, attach provenance and freshness, and produce an audit trail that answers "who gave us this row, when, and under what rights?"

The paid alternatives are portal-side scraping subscriptions, which put you on the wrong side of both the portal's terms and your own compliance team. If you already hold an authorized export, what you need is a deterministic normalization and evidence layer — not another crawler.

What the actor does

The PropertyFinder.ae UAE Real Estate Listings actor (slug propertyfinder-gulf, kept for existing Tasks) is the Authorized Gulf Property Listing Intelligence layer. Two modes:

Export mode (default, sourceMode: "export"). Fully network-free. You submit one to 100 closed property records you own or are licensed to process, and the actor normalizes them into review-ready evidence rows. Zero external-source requests: no portal page, no recorded URL fetch, no browser, proxy, API, DNS, robots, or sitemap call. Descriptions, photos, contact fields, and free text are deliberately rejected by the closed contract — unknown fields invalidate the record.
Live mode (sourceMode: "live"). Exactly one bounded request to an allowlisted public www.propertyfinder.ae results URL you supply, with a 15-second deadline, redirect/challenge/2 MB rejection, reading at most 100 RealEstateListing schema.org JSON-LD nodes. Live rows are marked property_listing_live with sourceLicense: null — public visibility is not a licence or proof of availability.

Per the README, each delivered row carries:

The legacy-compatible listing fields (url, title, price, currency, deal_type, property_type, rooms, area_sqm, location, lat/lng, posted_date) plus a deterministic stableId (SHA-256 over source name plus listing ID) for joins.
Provenance and rights context: buyer-supplied sourceName, sourceLicense, optional sourceRetrievedAt, and the exact authorization attestation recorded as an operational gate — not legal proof.
freshness (fresh/aging/stale/unknown) computed only from your supplied retrieval time, change always not_measured (a single snapshot proves nothing), evidence-sufficiency confidence with explicit dataGaps, and mechanical pricePerSqm when area is supplied — explicitly separated from valuation or investment advice.
A mandatory human route: recommendedAction, review priority (HIGH/MEDIUM/LOW from freshness and locality coverage), and safeToAutomate always false.
Settlement-neutral billing intent on the row, with the authoritative paid/free/withheld/unknown reconciliation in the current-run KVS OUTPUT.

Deduplication is scoped to lowercase sourceName plus listingId and never merges across sources. Legacy search-style inputs (deal_type, emirate, max_items, max_pages, max_listing_age_days) are migration-only: one free diagnostic, no network access.

Example: input and output

The documented input (from the manifest and README):

{
  "sourceMode": "export",
  "schemaVersion": "2.0",
  "authorization": "I confirm I am authorized to process and deliver these property records",
  "sourceContext": "provider_licensed_export",
  "listings": [
    {
      "listingId": "listing-101",
      "listingUrl": "https://inventory.example.com/listing-101",
      "title": "Two-bedroom apartment in Dubai Marina",
      "price": 2450000,
      "currency": "AED",
      "dealType": "sale",
      "propertyType": "Apartment",
      "bedrooms": 2,
      "areaSqm": 128.4,
      "location": "Dubai Marina",
      "sourceName": "Licensed Gulf property export",
      "sourceLicense": "Buyer confirms downstream processing and delivery rights",
      "sourceRetrievedAt": "2026-08-12T12:00:00Z"
    }
  ]
}

The README's happy run-bound example shows the KVS OUTPUT receipt for that one paid row (trimmed):

{
  "status": "SUCCEEDED",
  "output": {
    "status": "COMPLETE",
    "input": {"requestedCount": 1, "uniqueCount": 1, "duplicateCount": 0, "invalidCount": 0},
    "run": {"deliveredRowCount": 1, "paidRowCount": 1, "freeRowCount": 0, "withheldRowCount": 0, "replaySafe": false, "safeToAutomate": false},
    "delivery": {"eventName": "result-found", "confirmedEventDelta": 1, "confirmedDatasetWrites": 1, "lastAttempt": {"state": "confirmed_paid"}}
  }
}

Pricing and the free limit

Pay-per-event: $0.005 per actor start plus $0.003 per delivered authorized row (result-found), with tiered discounts on paid Apify plans (the Store headline works out to $2.55 per 1,000 rows). The README computes start plus ten paid rows at $0.035; at list prices a 100-record run costs $0.005 + 100 × $0.003 = $0.305. Apify's free plan includes $5 of usage credits per month, which covers about 16 full 100-record runs — roughly 1,600 delivered rows — before you pay anything. Legacy migration and invalid-record diagnostics are free.

Try it

Normalize one authorized record first, reconcile the Dataset against the KVS OUTPUT receipt, then scale the batch: PropertyFinder.ae UAE Real Estate Listings.

For AI agents and MCP

The actor takes JSON in and returns structured JSON via the Apify API, and the README includes an Apify MCP server setup plus an "MCP or agent workflow" recipe: treat the actor as a deterministic normalization tool — an agent may propose a review task but cannot infer source authority, ownership, valuation, availability, or permission to contact. Integrations must read the current-run KVS OUTPUT as a separate run fact, never copy a final paid/free state into the pre-settlement Dataset row, and never blind-retry an unknown delivery.

How to Export YouTube Playlists Without a Paid API

Tim Zinin — Fri, 02 Oct 2026 07:25:03 +0000

The problem

Playlists are the unit of curation on YouTube — a competitor's "best of" collection, a course creator's syllabus, a brand's campaign list — and getting their contents into a spreadsheet means scrolling a page, copying titles, and losing the ordering that makes a playlist useful. The official YouTube Data API will hand you playlist items, but only after a Google Cloud project, an API key, and quota management you should not need for a read-only, one-off export.

A hand-rolled scraper has subtler traps. A playlist page returns at most 100 videos per request, so a naive parser silently presents a truncated list as complete. YouTube sometimes renders a video entry with no title at all. And a well-formed but nonexistent playlist id answers with HTTP 200 and zero videos — a silent-empty result that looks identical to success unless you know to check.

What the actor does

The YouTube Playlist Scraper takes any public playlist — the list= value or a full youtube.com/playlist?list=... URL, including playlists you do not own — and returns one flat JSON row per video: videoId, title, viewCountText, and position. No API key, no login, no browser; one GET request per playlist.

From the README:

Any playlist, no channel resolution. It accepts any list= value and never looks up channels or builds uploads-playlist ids — if all you have is a channel handle, the README points to the sibling youtube-channel-videos-list actor instead. Up to 50 playlists per run, duplicates deduplicated before any request, concurrency 1–20 (default 5).
One flat 13-field row regardless of outcome: requestedPlaylist, normalizedPlaylistUrl, videoId, position, title, viewCountText, source, status, confidence, partial, action, error, checkedAt.
Honest status boundary. status:"ok" and status:"partial" are the billed, video-bearing outcomes. A well-formed but nonexistent playlist returns status:"empty" with error:null (HTTP 200, genuinely zero videos); a malformed one returns status:"error" naming YouTube's own HTTP 404. Both are free, and the HTTP status is checked before any body parsing so the two can never be confused.
A measured 100-item ceiling, disclosed. When a page returns exactly 100 videos, every row is flagged partial:true with action:"flag-possible-truncation" — delivered and billed, but honestly marked as a possible sample rather than the complete list. The actor never paginates past the first page.
Missing titles are data, not failures. A title:null row still ships as ok/partial with action:"flag-missing-title", so you keep the video id and decide what to do with it.
View counts are display text. Every video row carries confidence:"display-text" as a standing reminder that viewCountText ("2.6M views") is YouTube's own rounded string, not an exact counter.
Hardened fetch layer. Host guard (only the three YouTube hosts), DNS-rebinding-safe SSRF protection with pinned addresses, byte caps, and manual redirect re-checks; every request sends the standard consent cookie and hl=en&gl=US so English parsing cannot silently return empty. No transcripts or comments, ever — the paths serving those are disallowed by YouTube's own robots.txt and never requested.

Each run also writes a one-time KVS OUTPUT roll-up: requested/delivered/paid/free/failed counts, replay safety, and any fatal error.

Example: input and output

The prefilled default input is a real, verified 10-video playlist:

{
  "playlists": ["PLBCF2DAC6FFB574DE"],
  "maxConcurrency": 5
}

The README's real happy-path row (position 1 of that playlist, verbatim):

{
  "requestedPlaylist": "PLBCF2DAC6FFB574DE",
  "normalizedPlaylistUrl": "https://www.youtube.com/playlist?list=PLBCF2DAC6FFB574DE",
  "videoId": "GvgqDSnpRQM",
  "position": 1,
  "title": "Andrew Willis, Skatepark Engineer",
  "viewCountText": "2.6M views",
  "source": "playlist-page",
  "status": "ok",
  "confidence": "display-text",
  "partial": false,
  "action": "ingest",
  "error": null,
  "checkedAt": "2026-08-17T20:17:57.854Z"
}

A nonexistent id such as PLBCF2DAC6FFB574DF comes back as one free summary row — status:"empty", videoId:null, action:"skip-not-found" — and a malformed value comes back status:"error" quoting the 404. Both cost nothing.

Pricing and the free limit

Pay-per-event: $0.005 per actor start plus $0.001 per delivered video (result-found), with lower per-event prices on paid Apify tiers (the Store headline works out to $0.85 per 1,000 delivered videos). At list prices, a full 100-video export costs $0.005 + 100 × $0.001 = $0.105. Apify's free plan includes $5 of usage credits per month, which covers about 47 full 100-video runs — roughly 5,000 delivered video rows — before you pay anything. Empty, error, and blocked-host rows are never billed.

Try it

Run the prefilled playlist with zero edits to see the real row shape, then feed your own list: YouTube Playlist Scraper.

For AI agents and MCP

The actor takes JSON in and returns structured JSON via the Apify API, and the README documents running it from an MCP client plus an agent/MCP pattern. The agent contract is two rules: branch on status (never on error alone — an empty row correctly has error:null), and treat partial/action as machine-readable caveats — flag-possible-truncation means "sample of the first 100," and flag-missing-title on an otherwise ok row is a valid outcome to keep, not a parse failure to retry.

How to See Which Companies Are Hiring Right Now Without a Paid API

Tim Zinin — Thu, 01 Oct 2026 19:25:04 +0000

The problem

"Which companies are hiring right now?" is the starting question for sales prospecting, recruiting, and competitive research — and answering it manually means opening a company's careers page, finding their ATS, and counting roles by hand for every account on your list. Commercial intent platforms will sell you an answer, but it arrives as a black-box score with no source evidence attached, at a price that only makes sense for a funded sales team.

The underlying data is actually public. Companies on Greenhouse, Lever, or Ashby publish their open roles on unauthenticated job-board endpoints that anyone can read. The work is in turning those raw feeds into a consistent, comparable signal across dozens of boards — and in being honest about what a job posting does and does not prove.

What the actor does

The Company Hiring Radar reads the public Greenhouse, Lever, and Ashby board APIs for tokens you supply and returns one normalized, evidence-backed observation per board. No login, no ATS API key, no proxies.

From the README:

Explicit or auto-detected boards. Best input form is provider:token — greenhouse:stripe, lever:spotify, ashby:ramp — where the token is the slug in the company's careers URL. A bare token (stripe) probes all three providers and picks the board with the most open roles.
Honest identity handling. A token is not a company. Bare-token rows disclose the picked board's declared name (ownerName/ownerWebsite) and any other real boards found under the same token (candidates, with sameName flags). The README's live examples make the point: bare pulse resolves to Pulse Healthcare on Greenhouse (2,615 roles) while an unrelated runpulse.com sits on Ashby (9 roles), and bare juno matches two genuinely different boards both named "Juno". Explicit provider:token input has nothing to guess.
Normalized hiring signals per board: total open roles, a plain-English activity band (light / active / strong / aggressive hiring, derived only from the current posting count), role counts by function (sales, marketing, engineering, product, leadership, data, ops, people, finance, support, legal), remote share, a full by-location breakdown, and how many roles carry a parseable posting timestamp inside your newWindowDays window (default 30).
Keyword highlights in matchedRoles — only the roles whose title, department, or function contains your keywords — plus the full normalized role list (title, function, location, remote flag, posted date with its postedAtBasis, apply URL) in one shape across all three providers.
Decision context on every row: stable entityId/observationId/eventId, evidence[] with provider URLs and HTTP status, evidenceCoverage, confidence score with reasons, explicit dataGaps, a conservative recommendedAction, and safeToAutomate: false. A run-level KVS OUTPUT reconciles requested, unique, delivered, paid, free-failure, withheld, and replay-safe state.

The README keeps the interpretation boundary in the data: open postings are research evidence — they do not prove headcount growth, budget, expansion, purchase intent, or permission to contact anyone. A clean 404 (no board) is a free row, distinct from a source failure, which is also free.

Example: input and output

Input from the manifest:

{
  "companies": ["greenhouse:stripe", "lever:spotify", "ashby:ramp"],
  "keywords": ["sales", "marketing"]
}

The README's real output row for ashby:ramp, trimmed:

{
    "source": "ashby:ramp",
    "provider": "ashby",
    "found": true,
    "matchBasis": "explicit",
    "signals": {
        "totalOpenRoles": 118,
        "hiringMomentum": "aggressive hiring",
        "salesHiring": 46,
        "marketingHiring": 16,
        "engineeringHiring": 30,
        "remoteShare": 0.93,
        "newRolesLast30d": 28
    },
    "matchedKeywords": ["sales", "marketing"],
    "summary": "ramp (ashby) — 118 open roles, aggressive hiring. Top: sales 46, engineering 30, marketing 16. 93% remote, 63 match your keywords, 28 new in last 30d."
}

Each of the 118 roles also appears in the normalized roles list with title, function, location, remote flag, postedAt, postedAtBasis, and apply URL.

Pricing and the free limit

Pay-per-event: $0.005 per run start plus $0.002 per successfully delivered company-board report (result-found) — one charge per board regardless of whether it contains 0, 10, or 500 roles, with lower per-event prices on paid Apify tiers. At list prices, a 100-board run costs $0.005 + 100 × $0.002 = $0.205. Apify's free plan includes $5 of usage credits per month, covering about 24 full 100-board runs — roughly 2,500 board reports — before you pay anything. Clean not-found and source-failure rows are never billed.

Try it

Paste three board tokens from careers pages you want to watch, check the candidates disclosures on any bare-token row, then schedule the watchlist: Company Hiring Radar.

For AI agents and MCP

The actor takes JSON in and returns structured JSON via the Apify API, and the README notes it is callable from the Apify API, the SDK, or the Apify MCP server. The integration guidance is written for agents: join rows across runs on entityId, gate downstream automation on OUTPUT.status === "COMPLETE" and replaySafe === true, keep evidence, confidence, and dataGaps attached so a bounded observation never becomes an overclaim, and treat matchedRoles as a human research queue — row-level safeToAutomate is always false.

How to Query Himalayas Remote Jobs as an API Without a Paid Plan

Tim Zinin — Thu, 01 Oct 2026 16:25:04 +0000

The problem

Remote-job discovery is oddly hard to do programmatically on a budget. Job boards want you on their website, and the "API" options are either enterprise-priced feeds or undocumented endpoints that break without warning. If you are a recruiter building a shortlist, a developer feeding a jobs database, or an automation builder who needs structured role facts — title, company, salary, location eligibility, application link — scraping individual job pages is fragile, slow, and rude to the source.

Himalayas.app is one of the friendlier sources: it publishes an official, public, no-auth JSON API and explicitly permits its use in applications, tools, databases, and job-board operators, with visible attribution. The only thing standing between that endpoint and your workflow is the plumbing: bounded requests, validated responses, clean rows, and honest limits.

What the actor does

The Himalayas Remote Jobs API actor turns one bounded Himalayas search into up to 20 clean, attributed job rows in an Apify Dataset. It is not a scraper — it sends exactly one request to the official /jobs/api/search endpoint per run and never touches a job page, never walks additional pages, and never submits an application.

From the README:

Predictable one-request runs. You select exactly one 1-based result page (page, 1–100); the actor does not paginate further. A successful run writes zero to 20 rows.
Full filter set: query (default software engineer), optional country, worldwide / excludeWorldwide (mutually exclusive), seniority (up to 6 levels), employmentTypes (up to 7), companySlugs (up to 10 canonical slugs like linear), timezone (e.g. UTC-5), and sort (relevant, recent, salaryAsc, salaryDesc, nameAToZ, nameZToA, jobs). Unknown fields and contradictory filter combinations are rejected before the source is contacted.
21 factual fields per row: role title, company name and slug, employment type, disclosed salary range (minSalary, maxSalary, salaryPeriod, currency), seniority, locationRestrictions and timezoneRestrictions, categories and parentCategories, publishedAt, expiresAt, the original applicationLink, and provenance (source, attributionUrl, sourceRequestUrl, fetchedAt, guid).
Attribution by design. Himalayas permits the API for tools and databases while requiring visible attribution, so every row carries source: "Himalayas", the attributionUrl, and the original application link. Employer descriptions, excerpts, and logos are deliberately excluded.
Fail-closed security posture. The only upstream host is himalayas.app on the fixed search path, with a 15-second timeout and a 2 MiB body limit; redirects, non-JSON responses, rate limits, incomplete records, schema drift, and non-Himalayas application links all fail closed instead of returning uncertain data.

Honest limits are documented: Himalayas caches its API data and refreshes roughly every 24 hours, so frequent polling adds no freshness; a valid query can return zero rows; 20 is a maximum, not a target; and salary, seniority, and eligibility values are source facts, not independently verified.

Example: input and output

The manifest's example input runs a broad recent-software search:

{
  "query": "software engineer",
  "worldwide": false,
  "excludeWorldwide": false,
  "seniority": [],
  "employmentTypes": [],
  "companySlugs": [],
  "sort": "recent",
  "page": 1
}

The README's illustrative output shape (it labels the company and values as fictional) shows all 21 fields:

{
  "source": "Himalayas",
  "attributionUrl": "https://himalayas.app",
  "sourceRequestUrl": "https://himalayas.app/jobs/api/search?q=software+engineer&sort=recent&page=1",
  "fetchedAt": "2026-09-01T10:00:00.000Z",
  "guid": "illustrative-guid",
  "title": "Senior Software Engineer",
  "companyName": "Example Company",
  "companySlug": "example-company",
  "employmentType": "Full Time",
  "minSalary": 120000,
  "maxSalary": 150000,
  "salaryPeriod": "year",
  "currency": "USD",
  "seniority": ["Senior"],
  "locationRestrictions": ["Worldwide"],
  "timezoneRestrictions": [],
  "categories": ["Software Development"],
  "parentCategories": ["Engineering"],
  "publishedAt": "2026-08-25T10:00:00.000Z",
  "expiresAt": null,
  "applicationLink": "https://himalayas.app/companies/example-company/jobs/illustrative-role"
}

Null salary or date values mean the source did not disclose that fact — they are not zero — and the README advises inspecting locationRestrictions and timezoneRestrictions together before treating a role as eligible.

Pricing and the free limit

Pay-per-event: $0.013 per actor start plus $0.001 per delivered job row (result-found), charged only after each row is successfully stored; a source failure or invalid response cannot create a paid event. A full 20-job run therefore costs $0.033 at list prices — the same cap the README's public example Task uses. Apify's free plan includes $5 of usage credits per month, which covers about 151 full 20-job runs — roughly 3,000 delivered job rows — before anything is charged. A zero-result run pays only the $0.013 start.

Try it

Run the public example Task preset or call the actor with your own filters: Himalayas Remote Jobs API.

For AI agents and MCP

The actor takes JSON in and returns structured JSON via the Apify API, so agents can call it directly with apify-client or plain HTTP, and the README ships an Apify MCP server setup for it. Himalayas also publishes its own AI-agent integration guide, and the actor is built for exactly that pattern: one bounded request, attributed factual rows, original application links for human review, and no page scraping — an agent gets clean job metadata it can branch on without ever touching an employer page.

How to Scrape Spotify Artist, Album and Playlist Data Without a Paid API

Tim Zinin — Thu, 01 Oct 2026 13:25:03 +0000

The problem

Music analytics, A&R research, and playlist campaign tracking all start with the same humble need: read the public card for a Spotify artist, album, or playlist — the name, the monthly-listener figure, the release year, the track count, the item and save counts. Doing that by hand means opening every page in a browser and re-typing numbers into a spreadsheet, which does not scale past a handful of targets.

The programmatic alternatives are poor fits for a small watchlist. The Spotify Web API requires an app, OAuth tokens, and approval, and it meters you into quotas you do not need for a dozen pages. A naive scraper has a worse problem, and it is counterintuitive: Spotify's card pages only render their structured data server-side for a plain, non-browser request. Send a real browser User-Agent and you get HTTP 200 with an empty client-side shell — about 156 KB of "Spotify – Web Player" with zero data in it. A confident-looking response containing nothing.

What the actor does

The Spotify Artist, Album & Playlist Scraper takes full Spotify URLs you already have — https://open.spotify.com/artist/<id>, /album/<id>, or /playlist/<id> — and reads the server-rendered application/ld+json block each page ships, with one plain non-browser GET per target. No login, no API key, no Web Playback SDK, no browser runtime.

From the README:

The non-browser rule is the product. The actor always sends its own declared, non-browser User-Agent — never a browser signature — because that is the only request shape Spotify answers with data. Every row carries a requestUserAgent field echoing the literal header sent, so you can verify the discipline on your own runs; an acceptance test fails the build if that header ever becomes a browser string.
Type comes from the URL path, never guessed: artist rows return name and Spotify's displayed monthly-listener figure; album rows return name, release type, release year, and track count; playlist rows return name, item count, and save count.
One flat 15-field row per target, regardless of outcome: input, found, type, spotifyId, canonicalUrl, name, releaseType, releaseYear, trackCount, monthlyListeners, itemCount, savesCount, error, requestUserAgent, checkedAt.
Honest negatives, free of charge. A nonexistent object comes back as Spotify's own genuine HTTP 404 (found:false, error:"http 404"), not a silent-empty page. A non-Spotify host is refused before any request is made (requestUserAgent:null proves nothing was sent). An HTTP 200 with no usable ld+json block is reported, never guessed at. Only found:true rows are billed.
Disclosed source instability. Playlist itemCount/savesCount can legitimately come back null on the same URL across repeated fetches — the README measured three of five back-to-back fetches carrying the structured counts and two not. The actor reports the null honestly instead of inventing a value.
Up to 50 targets per run, concurrency 1–15 (default 5), plus a one-time KVS OUTPUT run summary with requested/delivered/paid/free/failed counts and replay safety.

Limits are stated plainly: no search by name, no track lists, no audio, no full discography, no pagination of playlist contents — the card-level summary only. monthlyListeners and savesCount are Spotify's own rounded display text ("100.9M"), not exact internal numbers.

Example: input and output

Input is one required field:

{
  "targets": ["https://open.spotify.com/artist/06HL4z0CvFAxyc27GXpf02"],
  "maxConcurrency": 5
}

The README's real happy-path row for that artist URL, verbatim:

{
  "input": "https://open.spotify.com/artist/06HL4z0CvFAxyc27GXpf02",
  "found": true,
  "type": "artist",
  "spotifyId": "06HL4z0CvFAxyc27GXpf02",
  "name": "Taylor Swift",
  "monthlyListeners": "100.9M",
  "error": null,
  "requestUserAgent": "Mozilla/5.0 (compatible; spotify-artist-intel/0.1; +https://apify.com/zinin/spotify-artist-intel)",
  "checkedAt": "2026-08-17T20:32:57.777Z"
}

An album row in the same run returned name: "After Hours", releaseType: "album", releaseYear: 2020, trackCount: 14; a playlist row returned name: "Today's Top Hits", itemCount: 50, savesCount: "33.9M" (with a repeat fetch showing both counts as honest nulls).

Pricing and the free limit

Pay-per-event: $0.005 per actor start plus $0.002 per delivered card (result-found); the README computes 100 delivered cards at about $0.205 including the start fee. A run of 50 URLs where 10 are stale links is billed for the 40 it actually delivered, never for the 10 honest 404s. Apify's free plan includes $5 of usage credits per month, which covers about 24 full 100-card runs — roughly 2,500 delivered cards — before you pay anything.

Try it

Run the prefilled artist URL with zero edits to see a real row, then feed your own watchlist: Spotify Artist, Album & Playlist Scraper.

For AI agents and MCP

The actor takes JSON in and returns structured JSON via the Apify API, and the README documents an agent/MCP pattern plus the Apify MCP server setup. An agent that already holds a Spotify URL passes it into targets, branches on found before trusting any field, uses requestUserAgent to distinguish a locally blocked host from a genuine source 404, and treats a playlist row with null counts as "not available on this fetch" — a disclosed source behavior to re-run, not a defect to retry blindly.

How to Pull App Store App Intelligence Without a Paid API

Tim Zinin — Thu, 01 Oct 2026 10:25:03 +0000

The problem

Tracking a portfolio of iOS apps — competitors, prospects, or your own releases — sounds trivial until you do it by hand. Rating, review count, price, seller, size, age rating, in-app purchases, OS compatibility, and the latest release notes all live on each app's public App Store page, and copying them into a spreadsheet for dozens of apps, every week, is nobody's idea of a good time.

Building your own scraper is harder than it looks. The App Store page carries two JSON-LD blocks — the first is Organization with no rating at all, the second is SoftwareApplication with the data you actually want — so a parser that grabs "the first ld+json block" returns a confident, success-shaped response with an empty rating at HTTP 200. Several fields (seller, size, age rating, IAPs, compatibility) are not in any structured-data block at all; they sit in a plain-HTML "Information" grid, and release notes live in a separate server-rendered "Version History" panel. Apple's official APIs, meanwhile, want keys, enrollment, and rate-limit management you may not need for a simple watchlist.

What the actor does

The App Store App Intel actor reads the same public app-detail page any browser sees — no login, no Apple API key, no headless browser — and returns one flat JSON row per app. Give it a numeric App Store id (310633997), a slug+id pair, or a full Store URL; all three forms mix freely, up to 100 ids per run, with configurable concurrency (default 5, max 20).

From the README, the behavior that matters:

Correct JSON-LD block, proven on every row. It scans every ld+json block and selects by @type === "SoftwareApplication", never by position, and the evidence field states which block supplied the data ("block 2 of 2") on every delivered row.
Eight HTML-fallback fields. Seller, size, age rating, in-app purchases, and compatibility are parsed from the page's plain-HTML Information grid; whatsNew, version, and releaseDate come from the server-rendered Version History panel — no JavaScript execution needed.
Honest three-state contract. Every row is found, not_found (Apple's own confirmed HTTP 404), or error (blocked, timed out, unparseable) — and only found rows are billed. not_found and error rows are still written to the dataset with the reason, free.
Honest partials. If an HTML field is genuinely absent — the README's real Spotify row has inAppPurchases: null — the row is partial: true with confidence: "medium" instead of an invented value. Long Apple display texts are capped and truncated with a visible … marker.
Guards. URL input is hostname-checked against apps.apple.com exactly (never a substring), DNS is resolved and pinned against private/reserved ranges (SSRF/DNS-rebinding guard), responses are byte-capped at 3,000,000 with a truncated flag, and retries apply only to network failures, 429, and 5xx — never to a 404.

Region is fixed to the /us/ storefront — the only region verified live during the build. Reviews and keyword search are permanently out of scope because the relevant hosts' robots.txt disallow those paths.

Example: input and output

Input is minimal:

{
  "appIds": ["310633997"],
  "maxConcurrency": 5
}

The README ships real, verbatim run output. The happy path for WhatsApp (id 310633997), trimmed:

{
    "appId": "310633997",
    "status": "found",
    "evidence": "ld+json SoftwareApplication (block 2 of 2) + html fallback (8/8)",
    "confidence": "high",
    "partial": false,
    "error": null,
    "title": "WhatsApp Messenger",
    "ratingValue": 4.7,
    "reviewCount": 18424969,
    "priceText": "0 USD",
    "publisher": "WhatsApp Inc.",
    "seller": "WhatsApp Inc.",
    "sizeText": "392.2 MB",
    "whatsNew": "We update the app regularly to fix bugs, optimize performance and improve the experience. Thanks for using WhatsApp!",
    "version": "26.32.73",
    "releaseDate": "2026-08-17"
}

A nonexistent id returns status: "not_found" with evidence: "http 404 (App Store's own \"Not Found\" page)" — free. A blocked host returns status: "error" with error: "blocked host \"evil.example\" — only apps.apple.com URLs are accepted" before any request leaves the actor — also free. Each run also writes a one-time KVS OUTPUT summary with requested/delivered/paid/free/failed counts and replay-safety state.

Pricing and the free limit

Pay-per-event: $0.005 per run start plus $0.002 per delivered app (result-found), with subscription discounts on paid Apify plans (the Store headline works out to $1.70 per 1,000 delivered apps at the entry tier). At list prices, a 100-app watchlist run costs $0.005 + 100 × $0.002 = $0.205 — and a run where 8 of 10 ids resolve is billed for 8 delivered apps, not 10. Apify's free plan includes $5 of usage credits per month, covering about 24 full 100-app runs — roughly 2,500 delivered app records — before you pay anything.

Try it

Paste a handful of competitor ids, check the evidence and status fields on the rows, then schedule the watchlist: App Store App Intel.

For AI agents and MCP

The actor takes JSON in and returns structured JSON via the Apify API, and the README describes an agent/MCP pattern explicitly: callable from the Apify API, the SDK, or the Apify MCP server, with the flat status field designed to be branched on directly — found means real data (check partial for completeness), not_found means the app genuinely does not exist right now, and error means retry later or surface the error string. For change tracking, agents diff version, releaseDate, priceText, or ratingValue between scheduled runs, since the actor is stateless per run.

How to Scrape Storia.ro Listings in Bucharest Without a Paid API

Tim Zinin — Thu, 01 Oct 2026 07:25:03 +0000

The problem

Bucharest property workflows rarely start from a clean API. Listings arrive as exports — from owners, agents, partner feeds, or your own CRM — and every source shapes its fields differently: prices as text, rooms embedded in titles, timestamps in local formats, no licence context attached. Before any analyst can review a batch, someone has to normalize the records, deduplicate them, and document where each row came from. Done manually, that is spreadsheet work with no audit trail.

The paid alternatives are portal-side: scraping subscriptions or data contracts that re-sell marketplace content. If your organization already holds authorized exports, what you need is a normalization and evidence layer — deterministic IDs, freshness, explicit gaps, and a review queue — not another crawler.

What the actor does

The Storia Romania Real Estate Listings actor (Store slug storia-bucharest) is the Authorized Bucharest Property Export Normalizer. It processes buyer-owned, owner-authorized, or licensed property records and makes zero external requests — no marketplace, portal, browser, proxy, DNS, or child-Actor calls.

Per the README, each run:

Validates a closed input contract: unknown properties fail closed, malformed rows become explicit free diagnostics when other valid work exists, and duplicate (sourceRecordId, sourceName) identities are suppressed before billing.
Delivers one stable normalized Dataset row per accepted unique record, preserving the familiar listing fields (title, price, currency, deal type, property type, rooms, area, location, posting date) plus a deterministic stableId and rowDigest.
Carries provenance on every row: source name, source URL, licence statement, buyer-supplied retrieval time, and a changesMade transformation disclosure.
Computes freshness against your freshnessHours threshold (default 168) using only the supplied retrieval time, and a confidence score that measures contract completeness with visible gaps — not factual truth.
Routes every accepted row to review_required with safeToAutomate=false, and records settlement-neutral billing intent; the authoritative paid/free/withheld/unknown reconciliation lives in the current-run KVS OUTPUT.

Legacy portal-style inputs (deal_type, property_type, city, max_items, max_pages) still parse but perform no source request — they emit one free migration diagnostic explaining how to move to records. The README is unambiguous about boundaries: the actor never verifies availability, price, ownership, or legal status, and it takes no external action.

Example: input and output

The documented input submits bounded records with provenance:

{
  "schemaVersion": "2.0",
  "authorization": "I confirm I may process and commercially use these submitted records.",
  "sourceContext": "buyer_owned_export",
  "batchName": "storia-bucharest-evidence-review",
  "freshnessHours": 168,
  "records": [
    {
      "sourceRecordId": "demo-ro-001",
      "title": "Authorized Bucharest apartment export",
      "entityName": "Example property",
      "category": "residential-property",
      "occurredAt": "2026-08-01T09:00:00.000Z",
      "url": "https://exports.example.com/ro/demo-ro-001",
      "sourceName": "Licensed Romanian property export",
      "sourceLicense": "Buyer confirms owner, agent, or commercial feed permission.",
      "sourceRetrievedAt": "2026-08-01T10:00:00.000Z",
      "changesMade": "Whitespace and numeric representation normalized.",
      "attributes": {
        "price": 195000,
        "currency": "EUR",
        "deal_type": "sale",
        "property_type": "apartment",
        "rooms": 3,
        "area_sqm": 78,
        "location": "Bucharest, Romania",
        "posted_date": "2026-08-01T09:00:00.000Z"
      }
    }
  ]
}

The README does not ship a full dataset-row fixture; its field dictionary defines the delivered row: recordType, stableId, found, the listing fields above, observedAt, freshness, change, decisionConfidence with gaps, evidence, decision (always review_required), recommendedAction, priority, safeToAutomate=false, failureDiagnostics, billing, and rowDigest. For an accepted one-record run, the README's illustrative run binding is {"status":"SUCCEEDED","evidenceAccepted":true,"datasetRows":1,"resultFoundDelta":1} — one paid result-found event per delivered row. A live sample dataset is linked on the actor page.

Pricing and the free limit

Pay-per-event: $0.005 per actor start plus $0.002 per delivered normalized record (result-found), with subscription discounts on higher Apify tiers (the Store headline works out to $1.70 per 1,000 records at the entry tier). At list prices, 100 records cost $0.005 + 100 × $0.002 = $0.205 per run. Apify's free plan includes $5 of usage credits per month, which covers about 24 full 100-record runs — roughly 2,500 normalized records — before you pay anything. Migration, invalid, and duplicate diagnostics are free.

Try it

Start with a single authorized record, read the KVS OUTPUT receipt before the Dataset rows, then scale: Storia Romania Real Estate Listings.

For AI agents and MCP

The actor takes JSON in and returns structured JSON via the Apify API, so agents can call it directly, and the README includes an Apify MCP server setup plus an "MCP tool call" playbook. The playbook's rule is the one agents must encode: read KVS OUTPUT first, require the current runId, route review_required rows to a human with licence, gaps, freshness, and digest attached, and never treat safeToAutomate=false as permission to message, trade, publish, or modify an external system.

How to Scrape SS.ge Real Estate in Tbilisi Without a Paid API

Tim Zinin — Wed, 30 Sep 2026 19:25:03 +0000

The problem

Tbilisi property data is scattered across portals, agent inboxes, and licensed feeds. If you run a portfolio, an agency desk, or a market-analysis workflow, you typically already receive exports — from owners, agents, or a data partner — and the painful part is not finding listings, it is turning those heterogeneous exports into one consistent, reviewable evidence layer. Doing it by hand means reconciling spreadsheets, chasing missing provenance, and having no defensible answer to "where did this row come from and when was it retrieved?"

The paid alternatives push you toward portal scraping subscriptions or per-seat SaaS contracts. For teams who hold authorized exports, a normalization layer with stable identity, freshness, and explicit gaps is the more useful primitive — and it keeps source rights where they belong: with the buyer.

What the actor does

The SS.ge Georgia Real Estate Listings actor (Store slug ss-ge-tbilisi, kept for API continuity) is a provenance-preserving normalizer for Tbilisi property records. It is not affiliated with SS.ge, and its current version deliberately does not crawl the portal. It works in two modes:

Authorized-export mode (default). You submit buyer-owned, owner- or agent-authorized, or licensed-feed records as structured JSON. The actor validates a closed schema, deduplicates (sourceName, sourceListingId) identities, and makes zero source network requests — no browser, proxy, login, or URL fetching. Recorded listing and image URLs are never opened.
Live public observation mode (live_public_listing). Exactly one bounded, login-free request to a fixed, allowlisted public SS.ge Tbilisi results page, returning up to 20 source-visible listing cards (public_property_listing_observation rows). It is a single observation, not a crawl, and the description field is omitted because the public payload can contain broker contact text.

Every accepted unique record becomes one Dataset row carrying the property fields (URL, title, price, currency, deal type, property type, rooms, area, location, coordinates, posting date, description, images, floor), a deterministic stableId plus input/request/row digests, full provenance (source name, source URL, licence statement, retrieval time, changes made), freshness computed only from your supplied retrieval timestamp, an evidence-completeness confidence score with concrete gaps, and a decision block: review_required outcome, priority, and safeToAutomate: false. A run-level KVS OUTPUT receipt reconciles delivered, paid, free, withheld, and unknown counts. Legacy city_id-style inputs still parse but return a free migration diagnostic.

The README is explicit about boundaries: it does not verify availability, price, ownership, or investment quality, does not track changes across runs (change.status is always not_measured), and does not make property decisions — every row routes to human review.

Example: input and output

Authorized-export input (from the README; the example domains and listing are fictional fixtures):

{
  "schemaVersion": "2.0",
  "authorization": "I confirm I may process and commercially use these property records.",
  "sourceContext": "owner_or_agent_authorized_export",
  "batchName": "tbilisi-property-review",
  "freshnessHours": 168,
  "listings": [
    {
      "sourceListingId": "demo-tbilisi-001",
      "title": "Two-bedroom apartment",
      "price": 195000,
      "currency": "USD",
      "deal_type": "sale",
      "property_type": "Apartment",
      "rooms": 3,
      "area_sqm": 91,
      "location": "Tbilisi, Georgia",
      "posted_date": "2026-08-12T09:00:00.000Z",
      "url": "https://properties.example.com/listings/demo-tbilisi-001",
      "sourceName": "Example authorized property export",
      "sourceLicense": "Owner-authorized export for internal property review.",
      "sourceRetrievedAt": "2026-08-12T10:00:00.000Z",
      "changesMade": "Selected fields and normalized whitespace."
    }
  ]
}

The README's happy-path fixture for that record shows the shape of a delivered row (trimmed):

{
  "recordType": "licensed_property_record",
  "stableId": "licensed-property:…",
  "title": "Two-bedroom apartment",
  "price": 195000,
  "currency": "USD",
  "deal_type": "sale",
  "found": true,
  "partial": false,
  "freshness": { "status": "fresh", "basis": "buyer_supplied_source_retrieval_time" },
  "change": { "status": "not_measured", "basis": "single_authorized_export_record" },
  "decision": { "outcome": "review_required", "priority": "normal", "safeToAutomate": false },
  "billing": { "billingEligible": true, "eventName": "result-found", "settlementSource": "current_run_kvs_output" }
}

Pricing and the free limit

Pay-per-event: $0.005 per actor start plus $0.002 per delivered normalized record (result-found); the README's own table prices 100 records at $0.205 including the start event. Apify's free plan gives $5 of usage credits per month, which covers about 24 full 100-record runs — roughly 2,500 individual normalized records — before any charge. Free diagnostics (duplicates, invalid records, legacy migration) are not billed as results.

Try it

Normalize one authorized record first, reconcile the Dataset against the KVS OUTPUT receipt, then scale the batch: SS.ge Georgia Real Estate Listings.

For AI agents and MCP

The actor takes JSON in and returns structured JSON via the Apify API, so agents can call it directly with apify-client or the REST API; the README also ships an MCP server setup (https://mcp.apify.com with this actor's tool). Its warehouse recipe gives agents a deterministic contract: stableId as the natural identity, rowDigest for version comparison, and explicit instruction that the same stable ID with a different digest means "review a changed supplied record," not proof of a portal edit — with safeToAutomate: false preserved downstream.

How to Detect Newly Registered UK Companies Without a Paid API

Tim Zinin — Wed, 30 Sep 2026 16:25:03 +0000

The problem

Newly incorporated companies are one of the oldest lead seeds in B2B: a business that registered last week does not yet have an accountant, a bank, an insurer, or a software stack. The raw material is public — Companies House publishes every registration — but turning it into a usable list is tedious. You have to search the register keyword by keyword, check incorporation dates against your window, copy company numbers and status by hand, and somehow avoid counting the same entity twice when two keywords match it.

Commercial "new company data" feeds exist, but they bundle the same public register behind a subscription and often dress a registration up as qualified demand. For a small team that just wants "active companies matching these keywords, incorporated in the last N days," a bounded, pay-per-result tool is a better fit.

What the actor does

The New UK Company Detector queries the public Companies House search-results pages and returns the first results page of active companies matching your keywords, filtered to a configurable incorporation lookback window. There is no register API key and no bulk-data contract involved.

From the README, the concrete behavior:

Accepts up to 25 case-insensitive company-name keywords per run; case variants are deduplicated, and each keyword returns the first search page — typically up to about 20 active matches incorporated within the window.
windowDays bounds how recent "new" means: 1 to 365 days, default 60. maxConcurrency (1–20) controls parallel keyword searches.
Emits one row per unique company number with the official register facts: company name, company number, direct Companies House URL, incorporation date, legal type, status, and registered-office locality (town/region only).
Deduplicates across keywords inside the run: if two keywords return the same company, it is delivered and charged once, and the repeat increments duplicateCompanyCount instead of selling a duplicate row.
Wraps each row in decision metadata: which keyword and window produced it, observation timestamp, incorporation age and freshness band, an evidence confidence score with explicit dataGaps (website, industry, contacts, decision maker, commercial fit), a recommended enrichment-first action, action priority, and a plain-language interpretationBoundary.
Confirmed no-match and operational outcomes are explicit, free rows — never a silent empty dataset — and a run-level KVS OUTPUT receipt reconciles delivered, paid, free, withheld, duplicate, and failed counts.

The README is equally clear about what it never claims: a found row is a recent official registered-name observation — a lead seed requiring enrichment — not proof of trading activity, buyer intent, revenue, or consent to outreach. It also does not page beyond the first search result.

Example: input and output

The input is three fields:

{
  "items": ["capital", "consulting"],
  "windowDays": 60,
  "maxConcurrency": 5
}

The README does not ship a fixed output fixture; the dataset schema is a row per unique delivered company number. Per the field dictionary, a delivered company row carries entityId, companyNumber, officialCompanyUrl, companyName, incorporatedOn, status, companyType, addressLocality, plus keyword and searchWindowDays explaining why the row matched, observedAt / incorporationAgeDays / freshnessBand for timing context, confidenceScore / confidenceBand / confidenceConflict for evidence support, dataGaps listing what enrichment is still missing, sourceEvidence with the official register link, and routing fields recommendedAction (for example ENRICH_COMPANY_BEFORE_OUTREACH), actionPriority, and safeToAutomate. A live sample dataset is linked on the actor page for inspection before you integrate.

Pricing and the free limit

Pricing is pay-per-event: $0.005 per actor start plus $0.005 per delivered company evidence row (result-found), with lower per-event prices on paid Apify plans — the README headline works out to $4.25 per 1,000 rows at the entry discount tier. At list prices, a run delivering 100 companies costs $0.005 + 100 × $0.005 = $0.505. Apify's free plan includes $5 of usage credits per month, which covers about 9 such 100-row runs — roughly 1,000 individual company rows — before anything is charged. Explicit no-match and operational advisory rows are free.

Try it

Start with one narrow keyword and a 30–60 day window, inspect the official URLs and confidence fields, then schedule the watch: New UK Company Detector & Lead Seeds.

For AI agents and MCP

The actor takes JSON in and returns structured JSON rows plus a KVS OUTPUT receipt via the Apify API, so an agent can call it directly. The README documents both an apify-client recipe and an Apify MCP call (call-actor against zinin/new-company-detector, with an MCP server setup block), and its webhook consumer policy tells agents to branch on failureType and safeToAutomate and to send safeToAutomate=false rows to a human-review queue rather than treating a registration as outreach permission.

How to Monitor 1688 Supplier Prices and MOQ Without a Paid API

Tim Zinin — Wed, 30 Sep 2026 13:25:04 +0000

The problem

If you source from 1688, supplier terms move constantly: prices drift, minimum order quantities change, stock disappears, and tiered pricing gets quietly restructured. Catching those changes means comparing two exports — last month's and this month's — line by line, offer by offer, in a spreadsheet. With a real supplier list, that manual diff is slow, error-prone, and impossible to audit later.

The paid alternatives are not much better for this specific job. A SaaS "1688 API" wants recurring fees and often your supplier URLs or platform credentials, and it still hands you raw data rather than a reviewed change list. What a sourcing or procurement team actually needs is a deterministic diff of the offer data it already lawfully possesses, with evidence attached to every detected change.

What the actor does

The 1688 Supplier Price & MOQ Monitor is a comparison engine for buyer-owned, merchant-authorized, or licensed 1688 offer exports. One boundary up front: it does not scrape 1688. It makes zero source network requests — no login, no proxy, no API call, no offer-URL fetching. It processes only the JSON records supplied in the run input, and the README is explicit that it never verifies suppliers, prices, stock, or purchasing suitability.

What it does do, deterministically:

Normalizes text, currency, price tiers, string lists, and timestamps in closed previous and current snapshots, then diffs the top-level fields.
Detects changes in price range, MOQ, stock, pricing tiers, unit, supplier fields, badges, and promotions.
Emits one reviewable comparison row per unique offerId with a changeType of baseline_created, changed, no_change, or a diagnostic status — never an invented change.
Attaches a stable 1688-offer:<offerId> identity plus SHA-256 record and request digests for tamper comparison and downstream joins.
Computes freshness from your supplied retrieval time, an evidence-completeness confidence score with explicit data gaps, a review priority, and a recommended human action such as REVIEW_OFFER_CHANGE.
Always sets safeToAutomate:false and writes an authoritative settlement receipt to the key-value store OUTPUT, reconciling delivered, paid, free, and withheld counts for the exact run.

Legacy URL-based productUrls input still parses, but only produces one free migration diagnostic; those URLs are never fetched.

Example: input and output

Input is a closed JSON contract. Each offer carries a previous snapshot (null on the first comparison, which yields baseline_created), a required current snapshot, and provenance fields:

{
  "schemaVersion": "2.0",
  "authorization": "I confirm I am authorized to process and deliver these 1688 offer records",
  "sourceContext": "buyer_owned_1688_export",
  "watchName": "usb-c-supplier-review",
  "maxChanges": 20,
  "offers": [
    {
      "offerId": "1000406623486",
      "previous": { "offerId": "1000406623486", "title": "USB-C cable wholesale pack", "priceMin": 3.8, "priceMax": 4.6, "currency": "CNY", "moq": 100, "stock": 12000, "unit": "piece" },
      "current": { "offerId": "1000406623486", "title": "USB-C cable wholesale pack", "priceMin": 3.6, "priceMax": 4.4, "currency": "CNY", "moq": 100, "stock": 15000, "unit": "piece" },
      "sourceName": "Buyer-owned 1688 export",
      "sourceLicense": "Buyer confirms authorization to process and deliver this export.",
      "sourceRetrievedAt": "2026-08-13T00:00:00Z"
    }
  ]
}

For that input, the README's checked-in fixture delivers a dataset row whose core decision fields look like this (trimmed):

{
  "recordType": "china_1688_supplier_monitor",
  "entityId": "1688-offer:1000406623486",
  "changeType": "changed",
  "changedFields": ["priceMax", "priceMin", "priceTiers", "promotions", "stock"],
  "recommendedAction": "REVIEW_OFFER_CHANGE",
  "safeToAutomate": false
}

The run-level KVS OUTPUT receipt then reconciles the exact run: one requested, one unique, one delivered, one paid, zero failed, networkRequestsMade: 0, platformLoginUsed: false.

Pricing and the free limit

The actor is pay-per-event: $0.005 per actor start plus $0.006 per delivered comparison row (the item-checked event), with lower per-event prices on paid Apify plans. At those list prices, a 100-offer comparison run costs $0.005 + 100 × $0.006 = $0.605. Apify's free plan includes $5 of usage credits per month, which covers about 8 full 100-offer runs — roughly 830 individual comparison rows — before you pay anything. Free diagnostics (legacy migration, invalid records, duplicates) are not billed as results.

Try it

Run a one-record comparison first, verify the dataset row and the KVS OUTPUT receipt, then scale the batch: 1688 Supplier Price & MOQ Monitor.

For AI agents and MCP

The actor takes JSON in and returns structured JSON via the Apify API, so an agent can call it directly with apify-client or the REST API. The README ships an MCP server setup (https://mcp.apify.com with this actor's tool) and an "MCP or agent workflow" recipe: an agent may submit records already present in its authorized workspace, but it must not invent authorization, browse 1688, or decide a purchase — every row carries safeToAutomate:false, explicit gaps, and a human-review route by design.

How to Turn Company Domains Into Verified Work Emails Without a Paid API

Tim Zinin — Wed, 30 Sep 2026 10:25:03 +0000

The problem

Sales, recruiting and partnerships workflows all hit the same wall: you have a person's name and their company domain, and you need a work email address. The common shortcuts are guessing patterns (first.last@domain) and SMTP probing — both damage sender reputation, and a "mailbox accepted the message" probe proves nothing about who owns it. Paid people-search databases sell the same guess with a nicer UI.

The defensible alternative is boring and manual: open the company's own website, find the team page, and check whether the address is literally published next to the person's name. That does not scale past a handful of lookups.

What the actor does

The Domain to Verified Work Email actor automates exactly that check — and nothing more. For each {fullName, domain} pair (1–50 per run) it visits only the buyer-selected company's own website, reading at most four fixed pages in a fixed relevance order — /team, /about, /contact, then / — over HTTPS, honoring robots.txt fail-closed, with no login, proxy, CAPTCHA-solving or JavaScript execution. Per the README, every row lands in one of four outcome classes:

Published person match (billed): the literal address exists as visible text or a mailto: link, the full name appears in the same bounded context, the local part follows a personal-name form, and the same HTML document carries a schema.org Person JSON-LD assertion whose normalized name and email exactly match.
Published visible match: every condition holds except the schema.org assertion — the page prints the address in the person's own block with no competing person. This is what most real company sites publish.
Free candidate list: name-shaped addresses (jdoe@, jane@) that the page never prints next to the name are listed in candidateEmails for a human, never promoted to a match.
Honest free decision: no address, only role mailboxes (info@, press@ — listed in roleEmails), an ambiguous tie, a robots-blocked page, or a budget stop. Every free row still reports checked pages, unreachable pages and reasons.

Every row — paid or free — carries safeToAutomate: false and safeForOutreach: false: a published page proves the address is printed, not mailbox ownership, consent or deliverability. Role-token local parts (contact-us, recruiters, human-resources, …) never become paid rows, and hidden CSS content is excluded via offline layout evaluation before matching.

Example: input and output

{
  "people": [
    { "fullName": "King Lee", "domain": "visionwide.co", "companyName": "Visionwide" }
  ],
  "maxPagesPerPerson": 3,
  "maxConcurrency": 1
}

The README's published person match example (abridged to key fields):

{
  "recordType": "person_email_decision",
  "schemaVersion": "1.1",
  "fullName": "King Lee",
  "companyName": "Visionwide",
  "domain": "visionwide.co",
  "email": "king.lee@visionwide.co",
  "verificationStatus": "published_person_match",
  "matchScore": 100,
  "matchReasons": ["literal_email_published", "full_name_on_page", "schema_org_person_name_email_assertion"],
  "sourceUrl": "https://visionwide.co/team",
  "sourceEvidence": { "schemaOrgPersonAssertion": true, "publicationChannel": "visible_text" },
  "roleEmails": ["info@visionwide.co"],
  "checkedPages": [
    { "path": "/team", "status": 200 },
    { "path": "/about", "status": 200 }
  ],
  "confidenceBand": "high",
  "recommendedAction": "ingest_evidence_then_apply_your_legal_outreach_policy",
  "safeToAutomate": false,
  "safeForOutreach": false,
  "found": true,
  "chargedEvent": "result-found"
}

Pricing and the free limit

Pay-per-event: $0.005 per run start plus $0.01 per published person match. A published visible match is billed only while its visible-match-found event carries a Store price — otherwise it is free. Every other outcome (candidates, role mailboxes, no-match, ambiguous, partial, robots-blocked) costs nothing beyond the start fee. A run delivering 100 published matches costs $0.005 + 100 × $0.01 = $1.005. Apify's free plan gives $5 of usage credits per month, so $5 covers about 4 such runs — roughly 400 verified addresses — plus any number of free-outcome rows at the start fee.

Try it

Submit a name and a domain, and read the evidence-tagged row before any outreach decision: Domain to Verified Work Email

For AI agents and MCP

The actor is built as a machine-first microservice: a closed input schema, a uniform 34-field row shape regardless of outcome, and a schema-validated OUTPUT summary — callable from the Apify API, a scheduled task, or the hosted Apify MCP server documented in the README. An agent can switch directly on verificationStatus and gate spend on chargedEvent, with safeToAutomate and safeForOutreach fixed at false so a lookup can never silently escalate into an autonomous send.

How to Scrape Computrabajo Job Postings in LatAm Without a Paid API

Tim Zinin — Wed, 30 Sep 2026 07:25:03 +0000

The problem

Latin American job data — Mexico, Colombia, Chile, Argentina, Peru — usually arrives as exports: an employer's ATS dump, a recruiting partner's feed, a licensed regional batch. Those exports are messy in the same ways every time: duplicate postings, malformed timestamps, missing licence statements, and no stable way to tell whether a row was actually delivered and billed.

Scraping a job board directly is the obvious alternative, but it raises rights and fragility questions — and for Computrabajo specifically, the historical Store slug now belongs to a different kind of tool entirely. The painful part is rarely getting the data; it is turning it into clean, provenance-linked, review-ready records.

What the actor does

The Licensed LatAm Job Export Normalizer (the actor behind the computrabajo-jobs slug) is explicit about what it is today: it does not call Computrabajo or any other job board in export mode, makes zero source network requests, and is not affiliated with Computrabajo. Instead it:

Normalizes authorized exports: 1–100 structured job records you own or are licensed to use (buyer_owned_job_export, employer_authorized_export, ats_authorized_export, other_licensed_job_export), validated against a closed schema — unknown fields, bad types, impossible timestamps and control characters are rejected from paid work.
Deduplicates before billing on case-insensitive sourceName + sourceJobId, with a free diagnostic reporting suppression.
Preserves provenance on every row: source name, source URL, licence statement, retrieval timestamp and transformation disclosure are required fields, never optional.
Adds review machinery: stable deterministic IDs, input and row digests for idempotent ingestion, freshness computed from the buyer-supplied retrieval time, a deterministic contract-completeness confidence score with explicit gaps, a human-review summary and priority — and safeToAutomate: false on every row.
Reconciles the run: a KVS OUTPUT receipt records requested, unique, duplicate, invalid, delivered, paid, free, withheld and unknown counts, with an exact +1 named-event check per paid row.

Legacy country:query inputs still parse but produce a free migration diagnostic — no board is queried. An optional sourceMode: "live" observes exactly one bounded public Computrabajo search page, clearly labelled actor_fetched_public_page, without inheriting export-mode authorization.

Example: input and output

The documented minimal licensed-export input:

{
  "schemaVersion": "2.0",
  "authorization": "I confirm I may process and commercially use these job records.",
  "sourceContext": "employer_authorized_export",
  "batchName": "latam-sales-review",
  "freshnessHours": 168,
  "jobs": [
    {
      "sourceCountry": "mx",
      "sourceQuery": "ventas",
      "sourceJobId": "demo-sales-001",
      "title": "Account Executive",
      "company": "Example Employer SA de CV",
      "companyRating": null,
      "location": "Ciudad de México",
      "postedAt": "2026-08-12T09:00:00.000Z",
      "url": "https://careers.example.com/jobs/demo-sales-001",
      "employmentType": "Full-time",
      "descriptionSnippet": "Buyer-supplied summary of the role.",
      "sourceName": "Example employer ATS export",
      "sourceUrl": "https://careers.example.com/exports/jobs",
      "sourceLicense": "Employer-authorized export for recruiting operations.",
      "sourceRetrievedAt": "2026-08-12T10:00:00.000Z",
      "changesMade": "Selected fields and normalized whitespace."
    }
  ]
}

A delivered row (licensed_job_record), excerpted from the README's checked example:

{
  "recordType": "licensed_job_record",
  "stableId": "licensed-job:…",
  "found": true,
  "title": "Account Executive",
  "company": "Example Employer SA de CV",
  "location": "Ciudad de México",
  "freshness": { "status": "fresh", "basis": "buyer_supplied_source_retrieval_time" },
  "change": { "status": "not_measured" },
  "decision": { "outcome": "review_required", "priority": "normal", "safeToAutomate": false },
  "billing": { "billingEligible": true, "eventName": "result-found", "settlementSource": "current_run_kvs_output" }
}

Pricing and the free limit

Pay-per-event: $0.005 per run start plus $0.002 per delivered normalized job record. Migration, invalid-record and duplicate diagnostics are free. Per the README's own table, 100 delivered records cost $0.205. Apify's free plan gives $5 of usage credits per month, so $5 covers about 24 such runs — roughly 2,400 normalized records.

Try it

Confirm the rights statement, map one authorized record, and reconcile the OUTPUT receipt before scaling the batch: Licensed LatAm Job Export Normalizer

For AI agents and MCP

The actor takes a closed JSON contract and returns schema-enforced rows plus a machine-readable OUTPUT receipt, callable from the Apify API, the SDKs, or the hosted Apify MCP server documented in the README. An agent can key idempotent ingestion on stableId and the row digest, route rows by freshness.status and decision.priority, and reconcile spend from the receipt's named-event counters — while safeToAutomate: false keeps every record in a human review queue.