How to scrape Workana project listings and read freelance demand

Workana is the largest freelance marketplace in Latin America, and its project listings are the closest thing there is to a public record of what LATAM clients are willing to pay for. Reading them is easy. Reading them correctly takes two decisions most tools get wrong.

What Workana exposes without a login

Project listings: title, description, budget, skills, category and subcategory, the client's country, their reputation signals, the proposal count, and the structured answers they gave Workana's posting form. Client names arrive already masked by Workana.

No login, no cookies, no proxy. Concurrency 3 is the measured default — at 5, Workana's own servers returned 5% HTTP 503, so the polite setting is again the reliable one.

Step 1 — use only the filters that filter

Workana accepts a lot of URL parameters and applies five of them: category, subcategory, skill, country and free-text search. Thirteen others return HTTP 200 and change nothing — budget_min, is_hourly, duration, payment_verified and nine more. The full list and how they were tested.

Step 2 — pick the locale deliberately

locale looks cosmetic and is not. It changes the language Workana renders its text in, and with it the thousands separator: "USD 1,000" in English and "USD 1.000" in Spanish are both one thousand.

The Actor parses per locale and records which one was used on every row, so the parse is checkable. Why that is a three-orders-of-magnitude problem if you get it wrong.

Step 3 — set a cap you understand

maxItems defaults to 500, and the site's own limit sits below that for a single query: 7 projects per page, no page 51, so about 350 projects per query for everyone. Bigger runs come from more queries, and the Actor splits by country automatically — an axis measured at 4% overlap and 6.8x more unique projects across six countries.

Step 4 — run it and read the coverage report

{
  "subcategory": "web-development",
  "country": "AR",
  "maxItems": 500,
  "locale": "es",
  "maxCacheAgeHours": 6
}

Then read COVERAGE in the key-value store. One entry per query: what Workana declared, what was delivered, whether the page-50 ceiling was hit, and how many projects are out of reach. If a run could not give you everything, the output says so rather than leaving you to assume — why there is no coverage percentage.

Reading budgets without breaking them

Three fields, in this order:

1. budget_type — `range` 70.6%, `max_only` 25.0%, `min_only` 4.4%. A null budget_min on a `max_only` budget is not missing data; there is no minimum to report.
2. budget_unit — `project` or `hour`. Mixing the two in one average produces a number that means nothing.
3. budget_raw — Workana's original string, kept so you can check the parse rather than trust it.

Reading client signals without discarding the market

client_rating is present on every project, and 80.5% of the values are 0.00 — which means “no ratings yet”, not “rated zero”. Filter on client_has_rating first or you will remove four fifths of the market believing you removed bad clients. The measurement.

client_payment_verified (true on 18.9%) and total_bids are the other two signals worth reading — and total_bids is time-sensitive, because the median goes from 1 proposal to 10 within twelve hours.

What a run costs

$0.002 per project and $0.00001 to start. Five hundred projects is a dollar. Failed requests go to ERRORS in the key-value store and are never charged — and if a run has no failures, no ERRORS record is created at all, because an empty error file suggests something went wrong when nothing did.

Four mistakes that waste a run

1. Filtering on a parameter that does nothing. You pay for rows you did not want and believe you filtered them.
2. Averaging budget_min. It silently drops the quarter of projects that never had one and biases the average upward.
3. Filtering on client_rating alone. Four fifths of the market disappears.
4. Judging competition from a day-old row. Proposal counts move in hours.