A filter that returns HTTP 200 and does nothing is worse than a filter that errors. You get a plausible result set, you believe it was filtered, and you pay for every row in it. Workana has thirteen of them.
The thirteen
| Parameter | What it looks like it does |
|---|---|
budget_min | Set a minimum budget |
budget | Filter by budget |
budget_from | Set a budget floor |
is_hourly | Only hourly projects |
hourly | Only hourly projects |
project_type | Filter by project type |
duration | Filter by expected duration |
published | Filter by publication date |
date | Filter by date |
urgent | Only urgent projects |
payment_verified | Only payment-verified clients |
max_bids | Cap by proposal count |
featured | Only featured projects |
Every one of them is accepted. Every one of them leaves the result set unchanged. Several are the exact filters somebody scraping a freelance marketplace would reach for first — a budget floor and a payment-verified flag are the two most obvious ways to narrow to serious work.
How they were tested
By comparison, which is the only method available without documentation: request the same query with and without the parameter and diff the result sets. If the sets are identical, the parameter did nothing regardless of what it returned.
A status code proves nothing here, and neither does a plausible-looking page. That is the whole lesson of this article: on an undocumented surface, the absence of an error is not evidence of an effect.
The one that makes things worse
language is not on the list above because it does not merely fail to narrow — it widens:
| Query | Projects declared |
|---|---|
country=BR | 2,826 |
country=BR&language=pt | 10,000 |
Ten thousand is Workana's counter cap, so the honest reading is “at least 10,000” — the parameter did not add Portuguese-speaking Brazilian projects to a Brazilian query, it loosened the country constraint. Somebody expecting a language filter would conclude the Brazilian market is 3.5 times bigger than it is.
The skill parameter that keeps only the first value
skill does work — for one value. Pass two and Workana keeps the first and silently drops the rest, so a two-skill query is a one-skill query that looks like two. Run one query per skill and union the results.
The empty run that looks correct
The related failure is a wrong slug. react returns zero projects with HTTP 200; react-js returns hundreds. Nothing distinguishes that from a skill nobody is hiring for.
So the Actor validates the slug before the run starts and reports what is wrong instead of charging for nothing — the slug reference.
Why the Actor does not offer them anyway
It would be easy to expose all eighteen parameters and let users find out. The reason not to is that it would be a lie with a plausible cover story: the input form would promise a budget filter, the run would return unfiltered rows, and the user would pay per row for the difference.
The five that work
- category — one of eight top-level categories.
- subcategory — 61 of them, and the axis that narrows a large category most.
- skill — one value, exact slug.
- country — the client's country, and the axis the Actor splits large queries along.
- query — free text, the only axis without a fixed vocabulary.
Everything else you want to filter on — budget, hourly, payment verification, proposal count — is a column in the output. Filter it in your own query, and accept that you paid for the rows you discarded, because that is the true cost of the site not supporting it.
