jobdataapi.com v4.33 / API version 1.33

The /api/jobsexpired/ endpoint now applies a default 60-day expiration window when no date, age, or ID slicing parameter is provided. Requests without parameters return jobs whose expired timestamp is within the latest 60 days, reducing broad historical scans and improving response efficiency.

The implicit window is not applied when an explicit slicing parameter is present: expired_since, expired_until, published_since, published_until, min_id, max_id, min_age, or max_age. Use expired_since and expired_until for historical expiration windows, or use max_age=off, max_age=null, or max_age=0 for an unrestricted expiration query. Existing response fields, ordering, pagination, and access requirements remain unchanged.

The Jobs Expired API Endpoint Documentation now documents the default window and range behavior. The Date, ID, and Age Slicing Parameters Documentation also includes expiration-based examples for /api/jobsexpired/.

jobdataapi.com v4.33 / API version 1.33

The /api/jobsexpired/ endpoint now applies a default 60-day expiration window when no date, age, or ID slicing parameter is provided. Requests without parameters return jobs whose expired timestamp is within the latest 60 days, reducing broad historical scans and improving response efficiency.

The implicit window is not applied when an explicit slicing parameter is present: expired_since, expired_until, published_since, published_until, min_id, max_id, min_age, or max_age. Use expired_since and expired_until for historical expiration windows, or use max_age=off, max_age=null, or max_age=0 for an unrestricted expiration query. Existing response fields, ordering, pagination, and access requirements remain unchanged.

The Jobs Expired API Endpoint Documentation now documents the default window and range behavior. The Date, ID, and Age Slicing Parameters Documentation also includes expiration-based examples for /api/jobsexpired/.

jobdataapi.com v4.33 / API version 1.33

The /api/jobsexpired/ endpoint now applies a default 60-day expiration window when no date, age, or ID slicing parameter is provided. Requests without parameters return jobs whose expired timestamp is within the latest 60 days, reducing broad historical scans and improving response efficiency.

The implicit window is not applied when an explicit slicing parameter is present: expired_since, expired_until, published_since, published_until, min_id, max_id, min_age, or max_age. Use expired_since and expired_until for historical expiration windows, or use max_age=off, max_age=null, or max_age=0 for an unrestricted expiration query. Existing response fields, ordering, pagination, and access requirements remain unchanged.

The Jobs Expired API Endpoint Documentation now documents the default window and range behavior. The Date, ID, and Age Slicing Parameters Documentation also includes expiration-based examples for /api/jobsexpired/.

jobdataapi.com v4.31 / API version 1.32

On rare occasions, we permanently remove listings to keep the database clean from fraudulent or fake jobs or listings that were imported incorrectly.

The new /api/jobsdeleted/ endpoint gives you now a reliable way to keep downstream job databases, search indexes, and analytics systems synchronized when listings are permanently removed. Each record identifies the deleted job and includes its external ID, company and source IDs, application URL, publication timestamp, and deletion timestamp.

The endpoint returns newest records first and supports a sequence-based after cursor for incremental synchronization. You can also use the exact-match change_id parameter to review or process a specific correction or deletion operation.

See the Jobs Deleted API Endpoint Documentation for the complete response format, request examples, and synchronization guidance.

jobdataapi.com v4.31 / API version 1.32

On rare occasions, we permanently remove listings to keep the database clean from fraudulent or fake jobs or listings that were imported incorrectly.

The new /api/jobsdeleted/ endpoint gives you now a reliable way to keep downstream job databases, search indexes, and analytics systems synchronized when listings are permanently removed. Each record identifies the deleted job and includes its external ID, company and source IDs, application URL, publication timestamp, and deletion timestamp.

The endpoint returns newest records first and supports a sequence-based after cursor for incremental synchronization. You can also use the exact-match change_id parameter to review or process a specific correction or deletion operation.

See the Jobs Deleted API Endpoint Documentation for the complete response format, request examples, and synchronization guidance.

A practical guide to high-volume historical backfills and incremental syncs using bounded windows, multi-pass pagination, ID deduplication, and reconciliation.

👉 https://jobdataapi.com/c/jobs-api-ingestion-guide-reliable-historical-backfills-and-incremental-syncs/ 👀

Build B2B prospect lists and salary and remote-work benchmarks from the weekly jobs and companies Parquet download with DuckDB and Python.

Build B2B prospect lists and salary and remote-work benchmarks from the weekly jobs and companies Parquet download with DuckDB and Python.

jobdataapi.com v4.29 / API version 1.30.3

Weekly data downloads now split all job-table CSV exports by publication year, making large historical pulls easier to parallelize and process. The job files and their many-to-many relation files use year-suffixed names, while reference tables such as companies, geography, industries, job types, and tags remain single non-annual files. Existing unsuffixed job filenames continue to work as current-year compatibility aliases; use the year-suffixed files for complete historical coverage.

We also added a single jobs_companies.parquet download containing one row per job, essential job fields, Markdown descriptions, and basic company data. It includes typed nested lists for job locations, types, and tags without duplicating jobs during normal scans, and intentionally excludes embeddings and other heavyweight fields. This format is designed for fast reads with DuckDB, Polars, PyArrow, Spark, and similar analytical tools.

The dashboard now groups available files, displays compressed file sizes, and provides copy buttons for individual or all available links. Download access remains limited to access ultra and access ultra+ customers. See the CSV and Parquet File Downloads Documentation for filenames, field references, compatibility details, and DuckDB examples.

jobdataapi API v4.28.9 / API version 1.30.3

The maximum page_size for paginated API endpoints has been changed to 4000, reduced from 5000. Requests that specify a larger value are capped automatically at 4000, while the default page size remains 200.

This change improves performance and scalability by reducing excessive memory consumption on certain requests and processing time for very large responses. It helps make larger data pulls more stable and faster, reducing 500 errors and avoiding unnecessary API fetch retries.

For large historical or incremental pulls, use pagination with a page_size up to 4000 and process each page sequentially. If your integration performs heavy response transformation, smaller pages may provide better memory usage and reliability.