Listings

1-200 (default 25). Anything else is a 422 bad_limit, not clamped.

The next_cursor from the previous page.

Employer flood control, opt-in (24 Oct 2026). company returns at most ONE row per employer per request: the newest row the walk reaches for that company in the published order, with the roles behind it read and hidden. Every returned row then carries company_more_roles. Without this parameter the response is exactly what it has always been. The rows behind a collapsed row are NOT deferred: next_cursor resumes after the last row the request decided on, so a hidden row never returns on a later page. A collapsed page therefore carries at most limit rows and often fewer (one employer flooding the window collapses to one row). Ordering is never changed: the published posted_at DESC NULLS LAST, id DESC contract holds. Counts are untouched: include_total and every count surface still count matching ROWS, not employers. Only the rows actually returned are charged as records.

Employer flood control, opt-in (24 Oct 2026): at most N rows of one employer per request (1-200). Rows beyond N are read and hidden where they stand, never deferred to a later page, so a page carries at most limit rows and often fewer. Counts (include_total, the facet chips) still count every matching row. max_per_company=1 agrees with collapse=company and may be sent with it; any other value together with collapse=company is a 422 flood_params_conflict, because the two contradict each other. Unlike collapse=company it adds no field to the rows.

live (default) returns open vacancies. closed returns roles that have left their source. any returns both; every row carries status. Paid endpoints only.

Re-admits vacancies whose poster is a staffing agency or a job board. Excluded by DEFAULT: the posting is real and the apply link is the poster's own, but the poster is not the employer, and one agency with thousands of listings (18,000 in one case, measured 19 Aug 2026) can flood a category until search stops being useful. Comma-separated. Paid endpoints only. An unrecognised value is a 422.

all re-admits rows we have GATED -- reversible doubt, such as a future posted_at or a missing apply URL. It never re-admits rows we have REMOVED: those breach the employer-direct guarantee and no query parameter may opt back into it. Each returned row carries its verdict, its rule id and the matched host. Paid endpoints only.

Comma-separated. uncategorised selects rows with no confident classification.

Alias for category (the facet key in /v1/meta/facets is named family; the filter parameter was category). Both names are accepted everywhere category is.

Comma-separated ISO-3166 alpha-2, at most 60 codes (more is a 422 too_many_values, never truncated).

Comma-separated city names, matched exactly but case-insensitively in every script (city=αθήνα finds Αθήνα); accents must match. A two-letter term that is a US state code or a country code (what country= accepts, plus UK for GB) qualifies the other city terms instead of naming a second city, so city=Exeter, RI returns only Exeter in Rhode Island: the US state reading wins a collision, and a qualifier with no city term left (such as city=GB) is still matched as a city value.

Comma-separated two-letter US state codes, e.g. OH or OH,TX. Absent where we could not establish the state from the source; deliberately absent for ambiguous city names, so this filter under-reports rather than placing a job in the wrong state.

remote, hybrid, on_site, or not_stated.

Comma-separated: full-time, part-time, contract, temporary, internship (case-insensitive; full_time / part_time are accepted too); not_stated selects rows with none. Matches exactly the employment_type value the response shows, including values read from the posting page by the verification sweep (since 6 Oct 2026; before that only the harvested value was matched, about a sixth as many rows). Coverage, measured 23 Oct 2026: 39.3% of served rows carry a value (942,302 of 2,399,121); the rest say not_stated, because the source publishes no employment type. A contract-duration word alone (Permanent, Regular, CDI, Employee) is not read as Full-time.

Comma-separated (OR, up to 8, case-insensitive): employee, vendor, other, or unknown (alias not_stated). The employment RELATIONSHIP the posting states: employee is payroll employment under the posting country's law (including temp-agency and zero-hours work); vendor is a commercial/self-employed arrangement (freelance, B2B, 1099, C2C, Brazilian PJ); other is a stated hybrid national form that everyday understanding puts on neither side (Polish umowa zlecenie, Italian co.co.co., umbrella/portage arrangements, statutory non-employment internships, volunteering). The raw national term is retained internally and refines these over time. The row value is an ARRAY (dual-option adverts such as "CLT ou PJ" carry both options, main one first); the filter matches any element. unknown selects rows where the posting does not establish the relationship (nothing is ever inferred from silence), so at launch most rows are unknown. An unrecognised value is a 422 naming the legal list.

Comma-separated (OR, up to 8, case-insensitive): permanent, fixed_term, project_based, seasonal, apprenticeship, internship, other, or unknown (alias not_stated). The contract KIND the posting states. contract_category=permanent returns only postings that STATE permanence (CDI, unbefristet, tempo indeterminato, contrato indefinido, ...). A posting that merely says "Full-time" is unknown, because most employers do not state the contract kind and this API does not guess it. The row value is an ARRAY (dual-option adverts); the filter matches any element. other is a stated form none of the named values can represent (zero-hours, casual, per diem, Minijob, Werkstudent, ...), never a dumping ground for uncertainty.

Comma-separated (OR, case-insensitive): direct, agency, umbrella, or unknown (alias not_stated). Who the employer of record is: the advertiser itself, a temporary-work agency (the engagement is then employee, because EU and national law make agency workers employees of the agency, and contract_category describes the contract WITH the agency), or an umbrella / portage company. unknown selects rows where it is not established.

Comma-separated (OR, case-insensitive): full_time, part_time, flexible, or unknown (alias not_stated). The stated schedule; flexible covers adverts offering either schedule. Distinct from the frozen employment_type field, which this API keeps unchanged.

Comma-separated; not_stated selects rows with none.

Comma-separated list of the exact source systems to include, e.g. greenhouse,lever,workday. This is the ATS or board a vacancy came from, finer than source_type which buckets them. A name we do not publish is a 422, never a silently empty page. Up to 12 values.

Same vocabulary as provider, removed instead of kept.

Comma-separated provenance filter. The legacy spellings employer_ats, government and direct are still accepted and map onto ats, public_agency and career_site. Filter values are matched case-insensitively: category=engineering and category=Engineering are the same query. Enumerate the legal values with /v1/meta/facets.

Comma-separated company slugs.

ISO 639-1 two-letter language code of the posting text (e.g. de, fr, en). Comma-separated, up to 12 languages (OR).

Exclude postings in these ISO 639-1 language codes. Comma-separated, up to 12 languages. Rows with undetected language are kept.

Server-side filter on how trustworthy the job's country is (see field_sources.country). high keeps only rows that have a country that is NOT low-trust: published, or inferred by a rule or by gazetteer and language model agreeing (measured precision about 99.5%). low returns only the llm_inferred rows, whose country a language model alone read out of the location text (measured precision about 95%). Omit it to receive everything. Any other value is a 422 bad_country_confidence and no records are billed.

Server-side filter for commission-only postings (db/370, DQ rule v5). The only legal value is commission_only; any other value is a 422 bad_compensation_type and no records are billed. Informational field (see the compensation_type description on the Job schema).

Exclude postings the commission-only rule flagged (db/370). The only legal value is commission_only, matching the API's existing exclude_* convention (exclude_category, exclude_country, ...).

true returns only listings whose remote status the SOURCE stated: 284,334 of 2,437,027 live rows (11.7%). Without it you also receive the 2,147,930 (88.1%) where we inferred it from the location text, the title, or the presence of a named workplace city.

true (and structured) returns only rows whose salary the SOURCE published: the meaning this parameter has always had, kept so that adding derived salaries does not change the results of a query you already ship. any also includes figures we read out of the advert text (salary_source: parsed_description, reported as inferred). AI estimates are never published under any value.

true returns only the 2,318,210 live rows (95.1%) that carry a description.

Comma-separated. Returns only rows where EVERY named field is published in field_sources, a value the source carried, never one we derived. The response then also contains a completeness object saying how many live rows carry each of them. This is the answer to "only 12.6% of your rows have a salary". They do, and require_fields=salary returns 307,796 rows of which 100% carry a figure an employer actually wrote, with no estimate anywhere in the response. Check the per-country split at /public/coverage/countries before you spend a record. category and seniority are refused with 422: both are read off the job title by our classifier, so they are inferred by construction and no row can ever satisfy them. An empty page would look like a coverage problem; the error says what it is. source_type is accepted and currently matches nothing: the per-row classification exists in the schema and no live row carries one yet. The completeness block reports that as a count rather than leaving you to infer it from an empty page.

Return the full advert text in a description field. Off by default: descriptions averaged 2,581 bytes (measured 5 Aug 2026), so a 200-row page would be a ~516 KB response nobody asked for. With this on, limit may not exceed 50: a larger request is refused with 422 rather than quietly clamped. Personal email addresses in the text are replaced with [personal contact removed]; company mailboxes and phone numbers are kept (see the description field).

Date or RFC3339 timestamp.

Only rows whose last_verified_at (the last positive confirmation at the source, see the Job schema) is at or after this instant.

Only rows that entered this API after this instant (date or RFC3339 timestamp), as recorded by the served-set ledger behind /v1/changes: new rows, and rows that came back after a withdrawal or re-opened after a closure, each counted from its latest entry. Use it to poll for new jobs, on any plan. posted_after cannot do that: posted_at is the employer's own date and is often days older than the moment a job reaches the API. Rows served since before 2026-10-23 06:11 UTC count from their first_seen_at. Poll with listed_after = <start of your previous poll> minus a few minutes and de-duplicate on id. On /v1/jobs/closed it selects closed rows that had entered after this instant.

Full-text over title, company name and location, NOT the description. That is deliberate, not a limitation: use description_contains for the advert body. Terms are ANDed. Without extended syntax a term matches whole words only (no stemming): q=engineer does not match engineering. Extended syntax, applied whenever it is used: - "customer support": exact phrase, adjacent and in order. - entwickler*: prefix match, which finds entwicklerin and the German gender-inclusive entwickler/in (one token to the tokenizer). Inside an extended query, terms of 5+ letters are prefix-matched automatically (remote finds remotely); quote a term for an exact match. - developer OR entwickler: either term. OR binds LOOSER than adjacency (2026-10-25): a b OR c d is (a b) OR (c d), so four word-pair alternatives written one after the other really are four alternatives. Until that date OR bound tighter and the same query read as a AND (b OR c) AND d. - (a OR b) c: parentheses group. They decide what an OR binds to. Around plain words with no OR inside they change nothing. - -berlin: exclude rows matching this term. The dash must touch the term; a free-standing dash is punctuation. A value the grammar cannot honour is refused with 422 query_syntax (an unmatched parenthesis, an empty group, an OR with no term on one side, a bare AND or NOT), never read as something else. Nothing is charged. Matching is case-insensitive in every script and accent-insensitive (2026-10-23): λογιστής, Λογιστής and ΛΟΓΙΣΤΗΣ are one query, and developpeur finds Développeur as développeur does. Localized syntax examples, one per customer language: German entwickler* and the exact phrase "software entwickler"; French développeur* and "service client"; Spanish desarrollador* and "marketing digital"; Dutch verpleegkundige* (prefix finds the plural). Works the same in every language the ledger carries.

Full-text over the job title only, e.g. ?title=engineer. It ANDs with every other filter, including ?description_contains=kubernetes over the advert body, but the two full-text filters together are the most expensive query this API can be asked, because both indexes are GIN and the matching rows still have to be fetched to be ordered by posted_at. Send them together on a narrow country or category, not on the whole ledger. Extended syntax (2026-10-07): quoted phrases ("software entwickler"), prefix (entwickler* or any bare word of 5+ letters), OR, and -word exclusions work exactly as they do on q, matched against the title only. Parentheses group and OR binds last (2026-10-25), as on q: a b OR c d is (a b) OR (c d). A plain value keeps the old AND-of-words behaviour. Case-insensitive in every script and accent-insensitive, as q (2026-10-23): title=ärztin, title=Ärztin and title=arztin are one query.

Drop rows whose title matches these words. Same matching, and the same extended syntax (phrases, prefix, OR, exclusions, parentheses), as title.

Full-text over the advert body. Only ever matches rows that have one, so it implies has_description=true. Extended syntax (2026-10-07): quoted phrases ("customer support"), prefix (kundenbetreuung* or any bare word of 5+ letters), OR, and -word exclusions work exactly as they do on q, with parentheses grouping and OR binding last (2026-10-25). A phrase matches the words in that order, anywhere in the body. Broad phrases over millions of adverts are the most expensive query this API can be asked; prefer a country or category alongside. A plain value keeps the old AND-of-words behaviour. Case-insensitive in every script (2026-10-23) for words the advert writes in lower case, Capitalised or in capitals. An accented term also finds the unaccented spelling; an unaccented term does not yet find accented advert text.

Comma-separated bare domains, e.g. stripe.com,figma.com: no scheme and no path, at most 100 (more is a 422 too_many_values, never truncated). The join key you already have in a CRM. 37.2% of companies carry a domain; the rest can never match this filter.

Same vocabulary as company_domain, removed instead of kept.

Lower bound on salary_min_annual_eur. Only rows whose salary could be normalised to an annual EUR figure can match (the current share is on /public/coverage, field salary_eur), so this is a narrow filter by nature, not a broken one. It compares every normalisable figure, published by the source or read out of the advert text (field_sources.salary and salary_source say which); add has_salary=true to compare only salaries the source published.

Upper bound on salary_min_annual_eur. Same scope as min_salary.

sort=relevance orders by where and how the query matches instead of recency: relevance-scored, band-weighted (title, category, company, location), tolerant of equivalents and abbreviations. Ordering-only: scores are comparable within a response, never across queries. Each row then carries a relevance object {score, tier} (tier one of exact, synonym, abbreviation, typo). Requires q and an API key; q must be under 200 bytes; other sort values are rejected. Deployment-gated. While the ranked mode is not enabled on the deployment (the case today), any sort value is refused with 422 sort_unavailable and nothing is charged; results are always newest first. It is never silently ignored.

Add total_estimate and total_estimate_status to the response: the number of rows matching the filters, exact up to 10,000 and page-independent. Costs one extra bounded query (at most 4 seconds; past that the page is still returned, with total_estimate_status: timed_out). Not charged as records.

The uuid or the public slug.

Return the row even if it has been delisted. It carries status="closed".

Comma-separated. uncategorised selects rows with no confident classification.

Alias for category (the facet key in /v1/meta/facets is named family; the filter parameter was category). Both names are accepted everywhere category is.

Comma-separated ISO-3166 alpha-2, at most 60 codes (more is a 422 too_many_values, never truncated).

Comma-separated city names, matched exactly but case-insensitively in every script (city=αθήνα finds Αθήνα); accents must match. A two-letter term that is a US state code or a country code (what country= accepts, plus UK for GB) qualifies the other city terms instead of naming a second city, so city=Exeter, RI returns only Exeter in Rhode Island: the US state reading wins a collision, and a qualifier with no city term left (such as city=GB) is still matched as a city value.

Comma-separated two-letter US state codes, e.g. OH or OH,TX. Absent where we could not establish the state from the source; deliberately absent for ambiguous city names, so this filter under-reports rather than placing a job in the wrong state.

remote, hybrid, on_site, or not_stated.

Comma-separated: full-time, part-time, contract, temporary, internship (case-insensitive; full_time / part_time are accepted too); not_stated selects rows with none. Matches exactly the employment_type value the response shows, including values read from the posting page by the verification sweep (since 6 Oct 2026; before that only the harvested value was matched, about a sixth as many rows). Coverage, measured 23 Oct 2026: 39.3% of served rows carry a value (942,302 of 2,399,121); the rest say not_stated, because the source publishes no employment type. A contract-duration word alone (Permanent, Regular, CDI, Employee) is not read as Full-time.

Comma-separated (OR, up to 8, case-insensitive): employee, vendor, other, or unknown (alias not_stated). The employment RELATIONSHIP the posting states: employee is payroll employment under the posting country's law (including temp-agency and zero-hours work); vendor is a commercial/self-employed arrangement (freelance, B2B, 1099, C2C, Brazilian PJ); other is a stated hybrid national form that everyday understanding puts on neither side (Polish umowa zlecenie, Italian co.co.co., umbrella/portage arrangements, statutory non-employment internships, volunteering). The raw national term is retained internally and refines these over time. The row value is an ARRAY (dual-option adverts such as "CLT ou PJ" carry both options, main one first); the filter matches any element. unknown selects rows where the posting does not establish the relationship (nothing is ever inferred from silence), so at launch most rows are unknown. An unrecognised value is a 422 naming the legal list.

Comma-separated (OR, up to 8, case-insensitive): permanent, fixed_term, project_based, seasonal, apprenticeship, internship, other, or unknown (alias not_stated). The contract KIND the posting states. contract_category=permanent returns only postings that STATE permanence (CDI, unbefristet, tempo indeterminato, contrato indefinido, ...). A posting that merely says "Full-time" is unknown, because most employers do not state the contract kind and this API does not guess it. The row value is an ARRAY (dual-option adverts); the filter matches any element. other is a stated form none of the named values can represent (zero-hours, casual, per diem, Minijob, Werkstudent, ...), never a dumping ground for uncertainty.

Comma-separated (OR, case-insensitive): direct, agency, umbrella, or unknown (alias not_stated). Who the employer of record is: the advertiser itself, a temporary-work agency (the engagement is then employee, because EU and national law make agency workers employees of the agency, and contract_category describes the contract WITH the agency), or an umbrella / portage company. unknown selects rows where it is not established.

Comma-separated (OR, case-insensitive): full_time, part_time, flexible, or unknown (alias not_stated). The stated schedule; flexible covers adverts offering either schedule. Distinct from the frozen employment_type field, which this API keeps unchanged.

Comma-separated; not_stated selects rows with none.

Comma-separated list of the exact source systems to include, e.g. greenhouse,lever,workday. This is the ATS or board a vacancy came from, finer than source_type which buckets them. A name we do not publish is a 422, never a silently empty page. Up to 12 values.

Same vocabulary as provider, removed instead of kept.

Comma-separated provenance filter. The legacy spellings employer_ats, government and direct are still accepted and map onto ats, public_agency and career_site. Filter values are matched case-insensitively: category=engineering and category=Engineering are the same query. Enumerate the legal values with /v1/meta/facets.

Comma-separated company slugs.

ISO 639-1 two-letter language code of the posting text (e.g. de, fr, en). Comma-separated, up to 12 languages (OR).

Exclude postings in these ISO 639-1 language codes. Comma-separated, up to 12 languages. Rows with undetected language are kept.

Server-side filter on how trustworthy the job's country is (see field_sources.country). high keeps only rows that have a country that is NOT low-trust: published, or inferred by a rule or by gazetteer and language model agreeing (measured precision about 99.5%). low returns only the llm_inferred rows, whose country a language model alone read out of the location text (measured precision about 95%). Omit it to receive everything. Any other value is a 422 bad_country_confidence and no records are billed.

Server-side filter for commission-only postings (db/370, DQ rule v5). The only legal value is commission_only; any other value is a 422 bad_compensation_type and no records are billed. Informational field (see the compensation_type description on the Job schema).

Exclude postings the commission-only rule flagged (db/370). The only legal value is commission_only, matching the API's existing exclude_* convention (exclude_category, exclude_country, ...).

true returns only listings whose remote status the SOURCE stated: 284,334 of 2,437,027 live rows (11.7%). Without it you also receive the 2,147,930 (88.1%) where we inferred it from the location text, the title, or the presence of a named workplace city.

true (and structured) returns only rows whose salary the SOURCE published: the meaning this parameter has always had, kept so that adding derived salaries does not change the results of a query you already ship. any also includes figures we read out of the advert text (salary_source: parsed_description, reported as inferred). AI estimates are never published under any value.

true returns only the 2,318,210 live rows (95.1%) that carry a description.

Comma-separated. Returns only rows where EVERY named field is published in field_sources, a value the source carried, never one we derived. The response then also contains a completeness object saying how many live rows carry each of them. This is the answer to "only 12.6% of your rows have a salary". They do, and require_fields=salary returns 307,796 rows of which 100% carry a figure an employer actually wrote, with no estimate anywhere in the response. Check the per-country split at /public/coverage/countries before you spend a record. category and seniority are refused with 422: both are read off the job title by our classifier, so they are inferred by construction and no row can ever satisfy them. An empty page would look like a coverage problem; the error says what it is. source_type is accepted and currently matches nothing: the per-row classification exists in the schema and no live row carries one yet. The completeness block reports that as a count rather than leaving you to infer it from an empty page.

Return the full advert text in a description field. Off by default: descriptions averaged 2,581 bytes (measured 5 Aug 2026), so a 200-row page would be a ~516 KB response nobody asked for. With this on, limit may not exceed 50: a larger request is refused with 422 rather than quietly clamped. Personal email addresses in the text are replaced with [personal contact removed]; company mailboxes and phone numbers are kept (see the description field).

Date or RFC3339 timestamp.

Only rows whose last_verified_at (the last positive confirmation at the source, see the Job schema) is at or after this instant.

Only rows that entered this API after this instant (date or RFC3339 timestamp), as recorded by the served-set ledger behind /v1/changes: new rows, and rows that came back after a withdrawal or re-opened after a closure, each counted from its latest entry. Use it to poll for new jobs, on any plan. posted_after cannot do that: posted_at is the employer's own date and is often days older than the moment a job reaches the API. Rows served since before 2026-10-23 06:11 UTC count from their first_seen_at. Poll with listed_after = <start of your previous poll> minus a few minutes and de-duplicate on id. On /v1/jobs/closed it selects closed rows that had entered after this instant.

Full-text over title, company name and location, NOT the description. That is deliberate, not a limitation: use description_contains for the advert body. Terms are ANDed. Without extended syntax a term matches whole words only (no stemming): q=engineer does not match engineering. Extended syntax, applied whenever it is used: - "customer support": exact phrase, adjacent and in order. - entwickler*: prefix match, which finds entwicklerin and the German gender-inclusive entwickler/in (one token to the tokenizer). Inside an extended query, terms of 5+ letters are prefix-matched automatically (remote finds remotely); quote a term for an exact match. - developer OR entwickler: either term. OR binds LOOSER than adjacency (2026-10-25): a b OR c d is (a b) OR (c d), so four word-pair alternatives written one after the other really are four alternatives. Until that date OR bound tighter and the same query read as a AND (b OR c) AND d. - (a OR b) c: parentheses group. They decide what an OR binds to. Around plain words with no OR inside they change nothing. - -berlin: exclude rows matching this term. The dash must touch the term; a free-standing dash is punctuation. A value the grammar cannot honour is refused with 422 query_syntax (an unmatched parenthesis, an empty group, an OR with no term on one side, a bare AND or NOT), never read as something else. Nothing is charged. Matching is case-insensitive in every script and accent-insensitive (2026-10-23): λογιστής, Λογιστής and ΛΟΓΙΣΤΗΣ are one query, and developpeur finds Développeur as développeur does. Localized syntax examples, one per customer language: German entwickler* and the exact phrase "software entwickler"; French développeur* and "service client"; Spanish desarrollador* and "marketing digital"; Dutch verpleegkundige* (prefix finds the plural). Works the same in every language the ledger carries.

Full-text over the job title only, e.g. ?title=engineer. It ANDs with every other filter, including ?description_contains=kubernetes over the advert body, but the two full-text filters together are the most expensive query this API can be asked, because both indexes are GIN and the matching rows still have to be fetched to be ordered by posted_at. Send them together on a narrow country or category, not on the whole ledger. Extended syntax (2026-10-07): quoted phrases ("software entwickler"), prefix (entwickler* or any bare word of 5+ letters), OR, and -word exclusions work exactly as they do on q, matched against the title only. Parentheses group and OR binds last (2026-10-25), as on q: a b OR c d is (a b) OR (c d). A plain value keeps the old AND-of-words behaviour. Case-insensitive in every script and accent-insensitive, as q (2026-10-23): title=ärztin, title=Ärztin and title=arztin are one query.

Drop rows whose title matches these words. Same matching, and the same extended syntax (phrases, prefix, OR, exclusions, parentheses), as title.

Full-text over the advert body. Only ever matches rows that have one, so it implies has_description=true. Extended syntax (2026-10-07): quoted phrases ("customer support"), prefix (kundenbetreuung* or any bare word of 5+ letters), OR, and -word exclusions work exactly as they do on q, with parentheses grouping and OR binding last (2026-10-25). A phrase matches the words in that order, anywhere in the body. Broad phrases over millions of adverts are the most expensive query this API can be asked; prefer a country or category alongside. A plain value keeps the old AND-of-words behaviour. Case-insensitive in every script (2026-10-23) for words the advert writes in lower case, Capitalised or in capitals. An accented term also finds the unaccented spelling; an unaccented term does not yet find accented advert text.

Comma-separated bare domains, e.g. stripe.com,figma.com: no scheme and no path, at most 100 (more is a 422 too_many_values, never truncated). The join key you already have in a CRM. 37.2% of companies carry a domain; the rest can never match this filter.

Same vocabulary as company_domain, removed instead of kept.

Lower bound on salary_min_annual_eur. Only rows whose salary could be normalised to an annual EUR figure can match (the current share is on /public/coverage, field salary_eur), so this is a narrow filter by nature, not a broken one. It compares every normalisable figure, published by the source or read out of the advert text (field_sources.salary and salary_source say which); add has_salary=true to compare only salaries the source published.

Upper bound on salary_min_annual_eur. Same scope as min_salary.

RFC3339 timestamp, or a next_since cursor from a previous call.

1-10000, default 1000.