> ## Documentation Index
> Fetch the complete documentation index at: https://docs.peopledatalabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Input Parameters - Job Posting Search API

# Input Parameters

## Field Filters

***

<br />

### `id`

| Type     | Description                    | Default | Example       |
| :------- | :----------------------------- | :------ | :------------ |
| `String` | PDL persistent job posting ID. |         | `+/vVJ9lbrec` |

**Functionality**\
This Field Filter matches records based on the `id` field.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter, and it filters to only exact matches for the specified `id` field.

See [Search by Exact Job Posting ID](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-exact-job-posting-id) for a working example.

***

<br />

### `first_seen_min`

| Type                        | Description                                                     | Default | Example      |
| :-------------------------- | :-------------------------------------------------------------- | :------ | :----------- |
| `String (Date, YYYY-MM-DD)` | Earliest date job was first seen by PDL (YYYY-MM-DD, inclusive) |         | `2026-01-01` |

**Functionality**\
This Field Filter matches records where the `first_seen` date is greater than or equal to the provided value.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter. Dates must be provided in the format `YYYY-MM-DD`.

See [Search by Exact Date](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-exact-date) for an exact-day example.

***

<br />

### `first_seen_max`

| Type                        | Description                                                   | Default | Example      |
| :-------------------------- | :------------------------------------------------------------ | :------ | :----------- |
| `String (Date, YYYY-MM-DD)` | Latest date job was first seen by PDL (YYYY-MM-DD, inclusive) |         | `2026-01-01` |

**Functionality**\
This Field Filter matches records where the `first_seen` date is less than or equal to the provided value.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter. Dates must be provided in the format `YYYY-MM-DD`.

See [Search by Exact Date](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-exact-date) for an exact-day example.

***

<br />

### `deactivated_date_min`

| Type                        | Description                                       | Default | Example      |
| :-------------------------- | :------------------------------------------------ | :------ | :----------- |
| `String (Date, YYYY-MM-DD)` | Earliest deactivated date (YYYY-MM-DD, inclusive) |         | `2026-01-01` |

**Functionality**\
This Field Filter matches records where the `deactivated_date` is greater than or equal to the provided value.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter. Dates must be provided in the format `YYYY-MM-DD`.

See [Recently Deactivated Jobs](https://docs.peopledatalabs.com/docs/examples-job-posting-api#recently-deactivated-jobs) for a date-range example.

***

<br />

### `deactivated_date_max`

| Type                        | Description                                     | Default | Example      |
| :-------------------------- | :---------------------------------------------- | :------ | :----------- |
| `String (Date, YYYY-MM-DD)` | Latest deactivated date (YYYY-MM-DD, inclusive) |         | `2026-01-01` |

**Functionality**\
This Field Filter matches records where the `deactivated_date` is less than or equal to the provided value.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter. Dates must be provided in the format `YYYY-MM-DD`.

See [Recently Deactivated Jobs](https://docs.peopledatalabs.com/docs/examples-job-posting-api#recently-deactivated-jobs) for a date-range example.

***

<br />

### `title`

| Type     | Description                  | Default | Example         |
| :------- | :--------------------------- | :------ | :-------------- |
| `String` | Job title of the job posting |         | `data engineer` |

**Functionality**\
This Field Filter matches job posting records using a `match_phrase` query against the cleaned `title` field in the dataset.

<Callout icon="📘" theme="info">
  **Example**

  Input: `data engineer`

  Titles that would be considered a match:

  * `Data Engineer` (case-insensitive)
  * `Senior Data Engineer` (substring match)

  Titles that would **not** be considered matches:

  * `Engineer, Data` (incorrect order)
  * `Data Science Lead` (missing “engineer” term)
</Callout>

**Cleaning**\
This input parameter is cleaned using our internal title cleaning logic (lowercased, whitespace trimmed, some normalization of abbreviations and punctuation). The cleaned input is matched against the `title` field and the `match_phrase` query supports case insensitivity and substring matches.

***

<br />

### `title_class`

| Type     | Description                                       | Default | Example                    |
| :------- | :------------------------------------------------ | :------ | :------------------------- |
| `String` | The PDL-assigned job class based on the job title |         | `research_and_development` |

**Functionality**\
This Field Filter matches records based on the `title_class` field.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter. It filters to only exact matches for the specified `title_class` field. You can provide a comma-separated list of values, and the API will match any of them.

`title_class` must be specified exactly as one of the [Canonical Job Title Classes](https://docs.peopledatalabs.com/docs/job-title-class)

See [Search by Title Taxonomy](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-title-taxonomy) and [Search by Multiple Title Taxonomy Values](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-multiple-title-taxonomy-values) for working examples.

***

<br />

### `title_role`

| Type     | Description                                      | Default | Example       |
| :------- | :----------------------------------------------- | :------ | :------------ |
| `String` | The PDL-assigned job role based on the job title |         | `engineering` |

**Functionality**\
This Field Filter matches records based on the `title_role` field.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter. It filters to only exact matches for the specified `title_role` field. You can provide a comma-separated list of values, and the API will match any of them.

`title_role` must be specified exactly as one of the [Canonical Job Title Roles](https://docs.peopledatalabs.com/docs/job-title-roles)

See [Search by Title Taxonomy](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-title-taxonomy) and [Search by Multiple Title Taxonomy Values](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-multiple-title-taxonomy-values) for working examples.

***

<br />

### `title_sub_role`

| Type     | Description                                          | Default | Example            |
| :------- | :--------------------------------------------------- | :------ | :----------------- |
| `String` | The PDL-assigned job sub role based on the job title |         | `data_engineering` |

**Functionality**\
This Field Filter matches records based on the `title_sub_role` field.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter. It filters to only exact matches for the specified `title_sub_role` field. You can provide a comma-separated list of values, and the API will match any of them.

`title_sub_role` must be specified exactly as one of the [Canonical Job Title Sub Roles](https://docs.peopledatalabs.com/docs/job-title-subroles)

See [Search by Title Taxonomy](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-title-taxonomy) and [Search by Multiple Title Taxonomy Values](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-multiple-title-taxonomy-values) for working examples.

***

<br />

### `title_levels`

| Type     | Description                                                 | Default | Example  |
| :------- | :---------------------------------------------------------- | :------ | :------- |
| `String` | The PDL-assigned job seniority level based on the job title |         | `senior` |

**Functionality**\
This Field Filter matches records based on the `title_levels` field.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter. It filters to only exact matches for the specified `title_levels` field. You can provide a comma-separated list of values, and the API will match any of them.

`title_levels` must be specified exactly as one of the [Canonical Job Title Levels](https://docs.peopledatalabs.com/docs/job-title-levels)

See [Search by Title Taxonomy](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-title-taxonomy) and [Search by Multiple Title Taxonomy Values](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-multiple-title-taxonomy-values) for working examples.

***

<br />

### `company_id`

| Type     | Description                        | Default | Example                        |
| :------- | :--------------------------------- | :------ | :----------------------------- |
| `String` | PDL company ID for the job posting |         | `LGrXE14x4Kvzj2cbaeRUngOCTuJA` |

**Functionality**\
This Field Filter matches records based on the `company_id` field.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter, and it filters to only exact matches for the specified `company_id` field.

See [Search by Company ID](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-company-id) for a working example.

***

<br />

### `company_name`

| Type     | Description                          | Default | Example     |
| :------- | :----------------------------------- | :------ | :---------- |
| `String` | PDL company name for the job posting |         | `anthropic` |

**Functionality**\
This Field Filter matches records based on the `company_name` field.

**Cleaning**\
Internally, this input parameter is run through our [Company Cleaner](https://docs.peopledatalabs.com/docs/cleaner-apis) to retrieve the `company_id` for the provided company name. The `company_id` is then used to filter results for exact matches. If no `company_id` is found, then the cleaned `company_name` is instead used to filter for exact results.

See [Basic Search: Company + Title](https://docs.peopledatalabs.com/docs/examples-job-posting-api#basic-search-company--title) for a working example.

***

<br />

### `company_website`

| Type     | Description         | Default | Example      |
| :------- | :------------------ | :------ | :----------- |
| `String` | Company website URL |         | `amazon.com` |

**Functionality**\
This Field Filter matches records based on the `company_website` field.

**Cleaning**\
Internally, this input parameter is run through the company cleaner. If a normalized website value is available, it is used for an exact match against `company_website`.

See [Search by Company Website](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-company-website) for a working example.

***

<br />

### `company_profile`

| Type     | Description              | Default | Example                       |
| :------- | :----------------------- | :------ | :---------------------------- |
| `String` | Company LinkedIn profile |         | `linkedin.com/company/amazon` |

**Functionality**\
This Field Filter matches records based on the `company_linkedin_url` field.

**Cleaning**\
Internally, this input parameter is run through the company cleaner. If a normalized profile value is available, it is used for an exact match against `company_linkedin_url`.

See [Search by Company LinkedIn Profile](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-company-linkedin-profile) for a working example.

***

<br />

### `location`

| Type     | Description                                                                                                  | Default | Example         |
| :------- | :----------------------------------------------------------------------------------------------------------- | :------ | :-------------- |
| `String` | Any location information for the job posting, such as street address, city, region, country, or postal code. |         | `united states` |

**Functionality**\
This Field Filter matches records based on the location-based information of a job posting record.

**Cleaning**\
Internally, this input parameter is run through our [Location Cleaner](https://docs.peopledatalabs.com/docs/cleaner-apis) to retrieve the standardized location information for the provided input, which is then used to filter results for matches on any location fields (such as country, region, postal code, etc).

<Callout icon="📘" theme="info">
  **Examples**

  Input: `germany`\
  Matches: job posts with any locations in the country of Germany

  Input: `stockholm`\
  Matches: job posts with any locations in the region of Stockholm, Sweden

  Input: `san francisco, california, united states`\
  Matches: job posts with any locations in the city of San Francisco, CA

  Input: `europe`\
  Matches: job posts with any locations on the continent of Europe
</Callout>

See the [Location filters](https://docs.peopledatalabs.com/docs/examples-job-posting-api#location-filters) examples for working examples at country, city, region, and continent levels.

***

<br />

### `description`

| Type     | Description                          | Default | Example |
| :------- | :----------------------------------- | :------ | :------ |
| `String` | The job description of the job post. |         | `LLM`   |

**Functionality**\
This Field Filter matches records based on the `description` field.

Specifically, this field filters results using a [`match_phrase`](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/query-dsl-match-query-phrase.html) query on the job posting description, meaning the filter is case-insensitive and supports partial matches (on exact substrings).

<Callout icon="📘" theme="info">
  **Examples**

  Input: `LLM`

  Descriptions that would be considered a match:

  * `Senior LLM Engineer` (Matches an exact substring)
  * `Experience with llm fine-tuning` (Case-insensitive match)
  * `Generative AI (LLMs)` (Matches the “LLM” sequence inside the plural “LLMs”)

  Descriptions that would **not** be considered matches:

  * `Large Language Model` (Even though the meaning is the same, the extra characters between the "LLM" abbreviation break the phrase match)
  * `ML/L L M` (The spaces between letters break the phrase match)
  * `L.L.M.` (The periods create a different character sequence than the input)
</Callout>

**Cleaning**\
There is no cleaning or standardization applied to this input parameter. However, it is matched against the job posting description field which has HTML tags removed, but formatting maintained using html2text.

See [Search by Description Text](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-description-text) for a working example.

***

<br />

### `salary_range_min`

| Type      | Description                             | Default | Example  |
| :-------- | :-------------------------------------- | :------ | :------- |
| `Integer` | The minimum salary for the job posting. |         | `100000` |

**Functionality**\
This Field Filter matches records based on the `salary_min` field.

Specifically, this field filters job posts where the posted `salary_min` value is greater than or equal to the provided input value.

**Cleaning**\
Input values are parsed into an integer value and searched against the `salary_min` field.

***

<br />

### `salary_range_max`

| Type      | Description                             | Default | Example  |
| :-------- | :-------------------------------------- | :------ | :------- |
| `Integer` | The maximum salary for the job posting. |         | `100000` |

**Functionality**\
This Field Filter matches records based on the `salary_max` field.

Specifically, this field filters job posts where the posted `salary_max` value is less than or equal to the provided input value.

**Cleaning**\
Input values are parsed into an integer value and searched against the `salary_max` field.

***

<br />

### `salary_currency`

| Type     | Description                                                | Default | Example |
| :------- | :--------------------------------------------------------- | :------ | :------ |
| `String` | The currency code for the listed salary in the job posting |         | `usd`   |

**Functionality**\
This Field Filter matches records based on the `salary_currency` field.

**Cleaning**\
Input values are case-normalized and searched against the `salary_currency` fields.

Input values must be one of the [Canonical Currency Codes](https://docs.peopledatalabs.com/docs/currency-codes).

***

<br />

### `salary_period`

| Type     | Description                                              | Default | Example  |
| :------- | :------------------------------------------------------- | :------ | :------- |
| `String` | The pay period for the listed salary in the job posting. |         | `annual` |

**Functionality**\
This Field Filter matches records based on the `salary_period` field.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter, and it filters to only exact matches for the specified `salary_period` field.

Input values must be specified exactly as one of the [Canonical Salary Periods](https://docs.peopledatalabs.com/docs/salary-periods)

***

<br />

### `remote_work_policy`

| Type     | Description                               | Default | Example  |
| :------- | :---------------------------------------- | :------ | :------- |
| `String` | The remote work policy of the job posting |         | `Remote` |

**Functionality**\
This Field Filter matches records based on the `remote_work_policy` field.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter, and it filters to only exact matches for the specified `remote_work_policy` field.

Input values must be specified exactly as one of the [Canonical Remote Work Policies](https://docs.peopledatalabs.com/docs/remote-work-policies)

See [Filter by Remote Work Policy](https://docs.peopledatalabs.com/docs/examples-job-posting-api#filter-by-remote-work-policy) for a working example.

***

<br />

### `inferred_skills`

| Type     | Description                                      | Default | Example      |
| :------- | :----------------------------------------------- | :------ | :----------- |
| `String` | Inferred skills from the job posting description |         | `javascript` |

**Functionality**\
This Field Filter matches records based on the `inferred_skills` field.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter. The filter uses a `match` query on inferred skills.

See [Search by Inferred Skills](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-inferred-skills) for a working example.

***

<br />

### `last_verified_min`

| Type                        | Description                                         | Default | Example      |
| :-------------------------- | :-------------------------------------------------- | :------ | :----------- |
| `String (Date, YYYY-MM-DD)` | Earliest last verified date (YYYY-MM-DD, inclusive) |         | `2026-01-01` |

**Functionality**\
This Field Filter matches records where the `last_verified` date is greater than or equal to the provided value.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter. Dates must be provided in the format `YYYY-MM-DD`.

See [Search by Last Verified Date](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-last-verified-date) for a working example.

***

<br />

### `last_verified_max`

| Type                        | Description                                       | Default | Example      |
| :-------------------------- | :------------------------------------------------ | :------ | :----------- |
| `String (Date, YYYY-MM-DD)` | Latest last verified date (YYYY-MM-DD, inclusive) |         | `2026-01-01` |

**Functionality**\
This Field Filter matches records where the `last_verified` date is less than or equal to the provided value.

**Cleaning**\
There is no cleaning or standardization applied to this input parameter. Dates must be provided in the format `YYYY-MM-DD`.

See [Search by Last Verified Date](https://docs.peopledatalabs.com/docs/examples-job-posting-api#search-by-last-verified-date) for a working example.

***

<br />

### `is_active`

| Type      | Description                                                                                      | Default | Example |
| :-------- | :----------------------------------------------------------------------------------------------- | :------ | :------ |
| `Boolean` | `true` returns only active posts (no `deactivated_date`); `false` returns only deactivated posts | `false` | `true`  |

**Functionality**\
This Field Filter matches records based on whether a job posting is active or deactivated.

**Cleaning**\
When omitted or blank, this field defaults to `false` and returns both active and inactive posts.

See [Active Jobs Only](https://docs.peopledatalabs.com/docs/examples-job-posting-api#active-jobs-only) for a working example.

***

## Elasticsearch Query

***

<br />

### `query`

| Type     | Description                                                                                                                                                                                                                                                                                                     | Default | Example                             |
| :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------ | :---------------------------------- |
| `Object` | An [Elasticsearch (v7.7) query](https://www.elastic.co/guide/en/elasticsearch/reference/7.7/query-dsl.html). See our underlying Elasticsearch mapping for reference. Using this field **disables and overrides** any [Field Filters](https://docs.peopledatalabs.com/docs/reference-job-posting-api#field-filters) provided in your API request. |         | `{"match": {"title": "developer"}}` |

#### Elasticsearch Query Limitations

We accept the following Elasticsearch query types:

* [term](https://www.elastic.co/guide/en/elasticsearch/reference/7.7/query-dsl-term-query.html)
* [terms](https://www.elastic.co/guide/en/elasticsearch/reference/7.7/query-dsl-terms-query.html)
* [exists](https://www.elastic.co/guide/en/elasticsearch/reference/7.7/query-dsl-exists-query.html)
* [bool](https://www.elastic.co/guide/en/elasticsearch/reference/7.7/query-dsl-bool-query.html)
* [match](https://www.elastic.co/guide/en/elasticsearch/reference/7.7/query-dsl-match-query.html)
* [range](https://www.elastic.co/guide/en/elasticsearch/reference/7.7/query-dsl-range-query.html)
* [match\_phrase](https://www.elastic.co/guide/en/elasticsearch/reference/7.7/query-dsl-match-query-phrase.html)
* [wildcard](https://www.elastic.co/guide/en/elasticsearch/reference/7.7/query-dsl-wildcard-query.html)
* [prefix](https://www.elastic.co/guide/en/elasticsearch/reference/7.7/query-dsl-prefix-query.html)
* [match\_all](https://www.elastic.co/guide/en/elasticsearch/reference/7.7/query-dsl-match-all-query.html)

We've disabled most specialized options, such as boosting and custom scoring, and we do not allow aggregations.

Any array in a query (such as a `terms` array) will have a hard limit of 100 elements. If a request goes over this limit, it will fail.

See the [Elasticsearch Query Examples](https://docs.peopledatalabs.com/docs/examples-job-posting-api#elasticsearch-query-examples) page section for working examples using `terms`, `exists`, `bool`, `must_not`, and `range` queries.

***

## Optional Parameters

***

<br />

### `size`

| Type      | Description                                                                                                  | Default | Example |
| :-------- | :----------------------------------------------------------------------------------------------------------- | :------ | :------ |
| `Integer` | The maximum number of matched records to return for this query if they exist. Must be between `1` and `100`. | `10`    | `100`   |

***

<br />

### `scroll_token`

| Type     | Description                                                                                                                  | Default | Example                                    |
| :------- | :--------------------------------------------------------------------------------------------------------------------------- | :------ | :----------------------------------------- |
| `String` | Each search API response returns a `scroll_token`. Include it in the next request to fetch the next `size` matching records. |         | `WzE3NzY0NzA0MDAwMDAsICIza2hMTDZ5dlR2MCJd` |

A `scroll_token` is returned in every Job Posting Search API response and serves as a placeholder or bookmark for the last record received. For queries with more results than can fit in a single API response (see the [`size`](#size) field), use the `scroll_token` to get the next batch of results.

For example, if you send a query to the Job Posting Search API that has 10,000 matches, you will need multiple API calls to retrieve all the records. The `scroll_token` represents how far along you are in that list of records.

Generally, the way to use `scroll_token` is:

1. Send a query to the Job Posting Search API.
2. Get a response back containing one batch of records as well as a `scroll_token` response value (if you have already retrieved all the available records in this batch, then the `scroll_token` value will be `null`).
3. Use the same query from Step 1 and the `scroll_token` you just received to make another request to the Job Posting Search API.
4. Get another response back with the next batch of records and a new `scroll_token` value.
5. Repeat steps 3 and 4 until you have received the desired number of records or until you receive a 404 status code because pagination is complete and the `scroll_token` key is missing from the response.

For a detailed working example of this process, see [Paginate with `scroll_token`](https://docs.peopledatalabs.com/docs/examples-job-posting-api#paginate-with-scroll_token).

***

<br />

### `pretty`

| Type      | Description                                                                               | Default | Example |
| :-------- | :---------------------------------------------------------------------------------------- | :------ | :------ |
| `Boolean` | Whether the output should have [human-readable](http://jsonprettyprint.net/) indentation. | `false` | `true`  |

***

<br />

### `api_key`

| Type     | Description          | Default | Example |
| :------- | :------------------- | :------ | :------ |
| `String` | Your secret API key. |         |         |

Your API Key **must** be included in either the request header or the `api_key` parameter. For more information about request authentication, see the [Authentication](https://docs.peopledatalabs.com/docs/authentication) page.