Gupy Jobs Scraper (Brazil)

Scrapes live vacancies from Gupy — Brazil's largest recruitment/ATS platform. Thousands of Brazilian companies host their careers pages on Gupy, and portal.gupy.io is the unified board across all of them: ~81,500 open roles at the time of writing.

Public data only. No login, no cookies, no browser, no bot challenge of any kind — the underlying API answers 200 on every TLS profile tested, including a request sent with no headers at all.

What makes this one unusual

Almost every other target in this portfolio has some flavour of silent wrongness — a bad filter that quietly returns unfiltered results. Gupy does the opposite. Its API rejects what it does not understand:

You send	Gupy answers
an unknown parameter name	HTTP 400 Bad Request
workplaceType=BOGUS	HTTP 200 with an honest total: 0
pageSize above 100	HTTP 400
a page past the 10,000-row window	HTTP 400

So you cannot get quietly-wrong data out of this actor. Bad inputs are refused before the run starts, with a message saying why.

The one thing it does get wrong

pagination.total is only truthful while the page size is 10 or less. From 11 upward it returns a hardcoded 100, whatever the real count — verified across filters and offsets. Since the efficient page size is 100, a naive client would report totalMatches: 100 for a search really matching 81,545.

This actor takes the total from one dedicated small probe per query, then pages at whatever size you asked for. That is the extra request you will see in requestsMade.

What you get

Two record types share one dataset, told apart by recordType.

JOB — one row per vacancy

Upstream's object passed through verbatim: job title, full HTML description, company name and logo, companyId, careers-page URL, direct apply URL, city/state/country, workplace type (remote / on-site / hybrid), contract type, published date, application deadline, accessibility badges and skills.

There is no "fetch details" toggle, and that is deliberate. Gupy's per-job endpoint (/api/v1/jobs/{id}) returns exactly the same keys as the search row — a detail pass would double the request count to re-fetch what is already in hand.

SEARCH_SUMMARY — one row per search term

The true match total, how many rows this run pulled, how many requests it took, the filters actually sent, and whether the query hit the 10,000-row window.

Input

Field	What it does
Search terms	one search each; leave empty to crawl the whole board
Workplace type	remote / on-site / hybrid
City	Brazilian city, accents included (São Paulo)
State	SP or São Paulo — the code is translated for you
Country	usually Brasil
Company ID	track one employer's hiring over time
Max jobs per search term	0 = unlimited, up to the 10,000 window

Example

{
  "searchTerms": ["desenvolvedor", "analista de dados"],
  "workplaceType": "remote",
  "state": "SP",
  "maxItems": 500,
  "pageSize": 100
}

Notes on reliability

• No WAF. chrome124, chrome120, chrome131, safari17_0, safari18_0, chrome99_android, edge101 and firefox133 all return 200, as does a bare request with no headers.
• robots.txt is Disallow: — an empty disallow, i.e. allow everything.
• HTTP 400 is treated as fatal, not retried. It means "your query is wrong", so retrying it four times just reaches the same answer slower.
• Residential proxy pinned to Brazil is the cloud default.
• Pagination stops before crossing the result window, so the run ends with a clean summary rather than an error row.

Known limits

• 10,000 rows per query, whatever the total says — an Elasticsearch-style result window. Narrow by city, state, workplace type or a more specific search term to reach the rest.
• state matches only the full accented Brazilian name upstream; the actor translates two-letter codes, but an unrecognised state string returns an honest zero rather than an error.
• Descriptions are raw HTML as the employer wrote them, not cleaned text.