jobdata

jobdata API Documentation

Get started with our simple jobdata API and be ready to fetch live jobs within minutes.

OpenAPI Schema + Redoc/Swagger UI

You can find the schema documentation in OpenAPI 3.0 format as well as a basic interactive Redoc and Swagger UI below:

To generate API client libraries, documentation and configuration automatically from the OpenAPI schema you might want to check out OpenAPI Generator

Endpoint Documentation

To access an endpoint without the hourly rate limit, you need to include the Authorization header with the value Api-Key YOUR_API_KEY, where YOUR_API_KEY should be replaced with your actual API key. For quick testing you can add your API key via the api_key GET parameter to every request instead, but make sure you don't leave traces of it in your browser history or simply create a new API key afterwards.

You can generate an API key from your dashboard if you're a subscribed customer. If you haven't subscribed yet please check our pricing page and hit Subscribe now on the plan that best suits your needs.

Currently there are up to five plans available for subscription:

  • access lite: Includes all features of our base access plan but is limited to a latest-jobs feed for the past 90 days and does not include date range, ID range or age-range slicing filters.
  • access: Our normal base plan with access to all job posts in the database and daily job data feed.
  • access pro: Adds full-text search with access to expired jobs info and full company data.
  • access pro+: Adds embeddings for every job post and basic vector search capabilities on top of all pro features.
  • access ultra: All of the above plus complete weekly database dumps in CSV and Parquet formats.

When a feature or endpoint requires the pro, pro+ or ultra plan it will be indicated by showing an access pro, access pro+ or access ultra badge next to it.

For the /api/jobs/ endpoint, requests default to a max_age=90 filter internally when no explicit max_age is provided. You can disable this behavior on non-lite plans by setting max_age=off, max_age=null or max_age=0.

Overview

The following is a comprehensive list of documentation pages for every API endpoint:

Also check out our tutorials section for a collection of quick guides and example use cases.

API Integration

To use the JobData API securely and efficiently, keep your API or download keys private and share them only with trusted team members or contractors. Never expose keys in frontend code, URLs, or public repositories, as this can compromise security.

The API is strictly for backend use and should not be accessed directly from the frontend, such as in-browser JavaScript. Frontend requests will fail due to CORS errors, and exposing your API key in the browser creates security risks. Always use a secure backend server to call the API and relay the data to your frontend.

To ensure a better user experience and avoid unnecessary delays, cache API results in your backend. This reduces the number of requests to the API, improves performance, and ensures faster delivery of data to users. Use appropriate caching strategies based on the type of data, such as job listings or company details.

Rate limits

All API endpoints are publicly acessible, except for parameters and queries that require a certain subscription. Without a valid API key there is a maximum of ~10 requests per hour that can be made for testing purposes. This should be sufficient to get a sneak peek into how the API works and what the response structures look like.

Besides throttling for anonymous requests there are no special limitations for authorized calls to the API. The only restriction is that a client should not send more than 10 requests per second to any API endpoint and not more than 2 requests in parallel. It is strongly recommended that you gear your implementation towards a sequential request pattern and cache as much data locally or within your application as possible.

This is more of a technical measure to avoid peak loads and flooding the API with too many requests at once, especially as some queries can become quite complex and may take longer to process.

Timeouts and 500 errors

In some rare cases the /api/jobs/ endpoint can return a 500 Internal Server Error when a query is too expensive to complete. This usually means that the database query timed out or that the server took too long to build and render the complete JSON response. These errors are most often caused by the shape and size of the request, rather than by invalid credentials or missing data.

As a general rule, use a page_size somewhere between 100 and 2000. Very small and very large pages are edge cases: page_size=1 can be unexpectedly slow for some query shapes, while page_size=4000 can make the database query, object serialization and JSON response too large or slow. If a request returns a 500, try increasing page_size from 1 or reducing a large page size before changing other filters.

For broad or complex requests, progressively narrow the result set:

  • Split a large backfill into smaller date windows with published_since, published_until, min_age or max_age.
  • Use min_id and max_id ranges to divide large result sets into manageable batches.
  • Prefer specific country, region, state, city, company or other filters over one broad query, and avoid very deep page numbers when ID or date ranges can be used instead.
  • Keep multi-keyword filters such as title, location and company filters reasonably short. Each additional include or exclude term can add more conditions to the query. The same applies to full-text searches with multiple keywords/phrases.

Only request response fields that are needed. In particular, avoid enabling tags=true, salary_extras=true, embed_3sh=true, description_md=true, description_str=true or location_str=true unless they are required. Set description_off=true when the full description is not needed; this can substantially reduce response rendering time and size.

Configure your API client's connection timeout to at least 45 seconds. A shorter client-side timeout can close the connection prematurely while the API is still processing a valid result, especially for larger but otherwise successful responses.

If a request returns 500, do not repeatedly retry the same broad query in parallel. Retry sequentially with a short backoff after reducing the page size, search terms or result range. A successful narrower request confirms that the original query needs to be split. This is different from a 429 Too Many Requests response, which indicates throttling.

Job Data Feed Examples by Topic

Job Data Feed Examples by Country

Explore jobdata API with AI tools

Ask an AI assistant how to search and build with live job data.