Skip to main content
Gupy is a Brazilian recruitment platform (ATS) used to open jobs, receive applications, evaluate candidates and register hires. The connector extracts data from the Gupy Public API (api.gupy.io) so you can analyze your whole hiring funnel in your Lakehouse: the jobs you open, the candidatures they receive with the candidate’s profile, the offers you send and what happens to each hire afterwards.

Configuring Gupy as a Source

In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Gupy option from the list of connectors. Click Next and you’ll be prompted to add your access.

1. Add account access

You’ll need a Gupy access token so Nekt can read your data. Sign in to the Gupy panel as an administrator, open Settings > Tokens Generation and create a new token with read permission for the data you want to extract. The token belongs to the company, so a single token covers every job and candidature of your account.
The Gupy public API is only available on the Premium and Enterprise plans. If the Tokens Generation screen is not available in your panel, talk to your Customer Success contact at Gupy — or open a ticket with their support — to have the API enabled before setting up this source.
The following configurations are available:
  • Access token: your Gupy access token. It is sent as a Bearer token on every request. This field is required.
  • Initial sync date: (Optional) the oldest candidature to extract, by creation date. Gupy offers no date filter on its endpoints, so this cut-off is applied while reading the data: it limits how much data is written to your Lakehouse, not how long the extraction takes. Leave it empty to bring your whole history.
  • Job statuses: (Optional) a comma-separated list of job statuses to read, for example published, closed. Only jobs in these statuses are extracted, along with their candidatures — a good way to speed up the extraction on companies with a long hiring history. Leave it empty to read every job. Allowed values: draft, waiting_approval, approved, disapproved, published, frozen, closed, canceled.
Once you’re done, click Next.

2. Select streams

Choose which data streams you want to sync. For faster extractions, select only the streams that are relevant to your analysis. You can select entire groups of streams or pick specific ones.
Tip: The stream can be found more easily by typing its name.
Application comments, Application rating criteria and Job offers are read one candidature at a time, because that is the only way Gupy exposes them. On companies with many candidatures they are by far the slowest part of the extraction — select them only when you need that data.
Select the streams and click Next.

3. Configure data streams

Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.
  • Layer: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
  • Folder: a folder can be created inside the selected layer to group all tables being created from this new data source.
  • Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
  • Sync Type: no Gupy endpoint accepts a “last updated” filter, so every stream of this connector is extracted as FULL_TABLE — each run brings the current state of your data, including status changes on candidatures created long ago.
Once you are done configuring, click Next.

4. Configure data source

Describe your data source for easy identification within your organization, not exceeding 140 characters. To define your Trigger, consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times). Optionally, you can define some additional settings:
  • Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here.
  • Determine when to execute an Additional Full Sync.
Once you are ready, click Next to finalize the setup.

5. Check your new source

You can view your new source on the Sources page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.
For you to be able to see it on your Catalog, you need at least one successful source run.

Good to know

  • Candidate data comes with the candidature. Gupy has no candidate endpoint of its own, so a candidate’s profile — name, contact, address, schooling, work experience — is returned attached to their application and is extracted in the Applications stream, in the candidate_ columns. The same person applying to three jobs appears in three rows, one per candidature.
  • Extraction cost grows with the number of jobs. Candidatures and the other per-job streams are read one job at a time, so narrowing the Job statuses setting is the most effective way to make a large account sync faster.
  • Permissions follow the token. If a module is not enabled for your company, or the token was created without permission for it, the corresponding stream is skipped with a warning in the run log instead of failing the whole extraction.
  • Nested data is stored as JSON text. Fields that hold a list of objects — a candidate’s work experience and academic background, the answers to a job’s additional questions, a job’s custom fields and position codes, the delivery history of an offer — are stored as JSON strings, so you can parse them in a Query without your table schema changing between runs.
  • Rate limits are respected automatically. Gupy allows 500 requests per minute per IP address. The connector backs off and retries when it is throttled, and pauses when Gupy reports the request window is nearly spent, so a large extraction slows down instead of failing.

Streams and Fields

Below you’ll find all available data streams from Gupy and their corresponding fields:
Job openings (vagas) of the company. This is the entry point of the connector: the per-job and per-candidature streams are expanded from the jobs listed here.Primary key: id · Sync type: FULL_TABLE
Candidatures (candidaturas) of every job, with the candidate’s profile unpacked into candidate_ columns. Gupy has no candidate endpoint of its own, so this stream is where candidate data comes from.Primary key: id · Sync type: FULL_TABLE
Selection steps (etapas) configured for each job. Read one job per request.Primary key: job_id · id · Sync type: FULL_TABLE
Position codes (códigos de vaga) attached to each job. Read one job per request. The same codes are also in the vacancy_codes column of Jobs.Primary key: job_id · id · Sync type: FULL_TABLE
Users that approve or qualify candidates in each job. Read one job per request.Primary key: job_id · id · Sync type: FULL_TABLE
Value each job filled in for the company’s custom job fields, one row per field. Read one job per request. The same values are also in the custom_fields column of Jobs.Primary key: job_id · id · Sync type: FULL_TABLE
Comments recruiters left on a candidate’s timeline. Read one candidature per request.Primary key: application_id · id · Sync type: FULL_TABLE
Ratings each recruiter gave a candidate on the job’s evaluation criteria, one row per rating. Read one candidature per request.Primary key: id · Sync type: FULL_TABLE
Hiring details recorded when a candidate is hired: salary, admission type and the position code filled. Only requested for candidatures whose status is hired.Primary key: application_id · Sync type: FULL_TABLE
Job offers (propostas) sent to a candidate, with their delivery history. Read one candidature per request.Primary key: id · Sync type: FULL_TABLE
Departments (departamentos) registered by the company.Primary key: id · Sync type: FULL_TABLE
Roles (cargos) registered by the company.Primary key: id · Sync type: FULL_TABLE
Branches (filiais) of the company, with their position in the organizational structure.Primary key: id · Sync type: FULL_TABLE
Career pages (páginas de carreira) where the company publishes its jobs.Primary key: id · Sync type: FULL_TABLE
Company users: recruiters, hiring managers and everyone else with access to the Gupy panel.Primary key: id · Sync type: FULL_TABLE
Access profiles that define what each company user is allowed to do.Primary key: id · Sync type: FULL_TABLE
Employees registered for internal recruitment.Primary key: id · Sync type: FULL_TABLE
Email templates used to communicate with candidates.Primary key: id · Sync type: FULL_TABLE
Job templates (modelos de vaga) used to create new openings.Primary key: id · Sync type: FULL_TABLE
Definitions of the company’s custom job fields: label, data type and available options.Primary key: id · Sync type: FULL_TABLE
Dismissals (desligamentos) reported back to Gupy for hired candidates.Primary key: id · Sync type: FULL_TABLE
Performance evaluations reported back to Gupy for hired candidates.Primary key: id · Sync type: FULL_TABLE