Upwork Talent Scraper — Freelancers, Rates & Earnings

Turn Upwork's public talent directory into clean, analysis-ready JSON. Search by keyword (or paste a filtered search URL) and get one structured record per freelancer — name, title, hourly rate, exact lifetime earnings, total hours, the hourly-vs-fixed job split, top-rated status, granular location, and a clean skills array. No login, no cookies, no API key.

This actor reads only the public, logged-out Upwork talent-search page — the same page any visitor sees — and parses the data Upwork itself ships in that page. It does not log in, solve a paywall, or touch private data.

---

Why this scraper

Most Upwork talent scrapers fall into one of two traps, and we fixed both:

• The "rich but wrong" trap. Some scrapers expose lots of fields but get the important numbers wrong — returning 0 lifetime earnings for clearly established, top-rated freelancers, or a broken job-success value. A market or rate analysis built on those numbers is quietly corrupted.
• The "clean but thin" trap. Others return correct values but only coarse buckets — a "$400K+ earned" string instead of a number, a single "Philippines" location string with no city or timezone, and no job-type split.

This actor ships the precise figure — total_earnings_usd is the exact number Upwork serves (e.g. 179240.68), not a bucket and not a zero — plus granular location (country / state / city / region / timezone) and the hourly/fixed/completed job-count split. Numbers you can actually sort, filter, and model on.

---

What you get — output fields

One row per freelancer:

Field	Description
freelancer_id, ciphertext, profile_url	Stable identity + public profile link
title, first_name, last_name, short_name, description	Headline + bio
hourly_rate_usd, currency	Listed hourly rate
total_earnings_usd	Exact lifetime earnings (the precise number, not a bucket)
earnings_hidden	true if the freelancer hides earnings (then the figure is withheld by Upwork)
total_hours	Lifetime tracked hours
total_hourly_jobs, total_fixed_jobs, total_completed_jobs	Job-count split
job_success_flag	Coarse job-success flag as shipped in the search payload (1/0, not a precise %)
is_top_rated, is_top_rated_plus, top_rated_status	Reputation badges
country, state, city, region, subregion, timezone	Granular location
skills, skills_count	Clean skill names (e.g. "Data Scraping", not a slug)
total_portfolio_items	Portfolio size
offers_consultations, is_diversity_certified	Profile flags
portrait_url	Avatar image URL
search_query, search_rank	Which query surfaced this profile, and its position
scraped_at	UTC timestamp

Honesty note on job-success: Upwork's public search payload exposes job-success only as a coarse flag, not the precise 0–100 Job Success Score shown on the full profile page. We surface it as job_success_flag and never dress it up as a percentage. The headline reputation signals you can trust here are the exact earnings, hours, job counts, and the top-rated badges.

---

Input

Input	Description
searchQueries	List of keywords, e.g. "python developer", "shopify expert". Each is searched and paginated.
searchUrls	Optional. Full talent-search URLs from the Upwork UI (with your skill/location/rate filters). Pagination is automatic.
maxProfiles	Ceiling on total freelancers returned (cost safety). Default 50. Upwork returns 10 per page.
country	Two-letter managed-access exit country. Default us.

Provide keywords, URLs, or both. Example:

{
  "searchQueries": ["python developer", "react developer"],
  "maxProfiles": 100
}

---

Pricing

This actor is pay-per-result: you are charged once per profile-result (one freelancer record). You only pay for the freelancers actually returned. The managed-access layer that reaches Upwork reliably is included in the price — you supply no proxy and no external key.

maxProfiles is a hard ceiling, so your spend is always bounded by the number of results you ask for.

---

Use cases

• Rate & market intelligence. "What do top-rated Python developers actually charge, and how much have they earned?" Sort by exact earnings and rate to benchmark a skill's market.
• Recruiting / sourcing. Build a shortlist of freelancers for a skill, filtered by location/timezone for overlap with your team, ranked by hours and job count.
• Agency competitive analysis. Track which freelancers in your niche are winning the most work and at what rates.
• Talent-supply signals. Feed a dataset of available freelancers per skill into your own pricing or staffing model.

---

How it works

Upwork's talent-search page renders its data into an embedded state blob. This actor reaches the public page through a managed-access service (the top rung of our access ladder, included as our cost — you pay nothing extra), parses the embedded freelancer state with a real JavaScript engine, and emits one clean, flat row per freelancer. A managed-access browser is used as an automatic fallback if the request path is ever challenged.

---

Notes & limitations

• Only public profile data that Upwork serves to logged-out visitors is returned. No private contact details, no login-gated fields.
• Freelancers who hide their earnings or job-success on Upwork will have those fields returned empty (earnings_hidden: true) — we never fabricate a value.
• Upwork shows up to ~1,000 pages of results per query; very deep pagination is bounded by maxProfiles.
• Field availability follows what Upwork exposes; if Upwork changes its page, the parser is built on structure (not brittle CSS class names) to stay resilient.

---

Legal

This actor collects only publicly available information from Upwork's logged-out talent-search pages. You are responsible for using the data in compliance with Upwork's terms and all applicable laws (including data-protection rules such as GDPR/CCPA where relevant). Do not use the data for spam or unlawful profiling.

More scrapers from our toolkit

Building a data pipeline? These actors pair well with this one — each runs on your own Apify account with the same pay-per-result pricing, no subscription:

• Website Contact Extractor
• Yellowpages Scraper
• Yelp Scraper
• Zoominfo Scraper
• 2GIS Places Scraper
• B2B Leads List Builder

Chain any of them together from the Integrations tab (the Run succeeded trigger) to build a multi-step workflow — one actor's output feeds the next.

Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as USAGE_STATS in your own Apify key-value store, so you can see the exact record created for your run.

Set disableUsageStats to true in the input to opt out. Nothing is sent then; your USAGE_STATS record only says that statistics were disabled.

Only these fields are recorded:

• schema version, Actor name and build number;
• UTC start and finish hour (not a precise timestamp);
• run duration, number of results and time to the first result, each as a coarse range;
• whether the result was empty, the end status, and an error type from a fixed list;
• memory setting and counts of charged events;
• names of the input fields you set, never their values;
• the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

Additional fields (Phase 2)

This Actor also records your Apify user ID, whether Apify marks the account as paying, the size range of list inputs, the selected country when the input offers a fixed list of countries, and one category from a fixed Actor taxonomy. We use these fields only for aggregate reliability, repeat-use and cross-Actor analysis; reports suppress any cell with fewer than five distinct users.

The same disableUsageStats: true input flag turns these fields off too. The user ID is removed after 13 months; we do not export, sell, share, or attempt to re-identify this data.

Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

• the result limit you asked for (a range, when the input has one) and what share of it was delivered;
• results delivered per input item you listed (a range);
• output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
• how the run was started (console, API, schedule, webhook, another Actor);
• how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
• if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
• a short code made from the names of the input fields you set, never their values.

Repeat-run fingerprint (v2)

When your Apify user ID is recorded (see above), the record also holds an 8-character one-way code made from your input (proxy settings left out) and this Actor's name. It only lets us see that the same account ran the same input again soon after an unsatisfying run; we never see the input itself. It is stored only in the database, never published, and reports use it in aggregate with the same five-user minimum. It is the one exception to the statement above that no hashes are collected, and disableUsageStats: true turns it off.