How to use a LinkedIn jobs scraper as an API

Choose a run pattern

Use Apify Console for exploration, an Actor Task for a reusable saved input, and the REST API when another application needs to start runs or retrieve data. An asynchronous API run is the safer production default because your request returns immediately and your application can poll the run status. A synchronous endpoint is useful only for small runs that finish within its response window.

Test before coding

Open the LinkedIn Jobs Search Scraper. Run one role, one location, and 25 results. Confirm that jobId, title, company, location, posting date, job URL, and optional description are suitable before integrating the API.

{
  "queries": ["machine learning engineer"],
  "locations": ["United States"],
  "includeDescriptions": true,
  "maxResultsPerQuery": 25
}

Download a bounded Python starter

Download the one-job starter ZIP for Job Details. Unzip it, follow its README to create a Python environment, and keep your Apify token in the local .env file. Never enter the token on this website.

python3 src/run_one_job.py --query "data engineer" --location "London"

The runner requests one row, a $0.05 pay-per-event charge ceiling, and a 120-second Actor timeout. It validates the job ID, source URL, title, company, and description before saving output/job.json. Optional fields may be empty. Review platform charges separately; the charge ceiling does not promise a free run. Offline tests do not prove that a live source will return a usable row.

A lost response may still have started a paid run. The starter does not automatically retry requests. Inspect the existing run in Apify Console before running it again.

Move from one job to a small CSV batch

After validating one result, create input/jobs.csv with one job_id column and up to ten unique current job IDs. The ZIP includes a companion runner for macOS, Linux, or Windows WSL. Preview the input without a token or network request:

python3 src/run_job_batch.py input/jobs.csv

Review live pricing, then explicitly execute the bounded batch:

python3 src/run_job_batch.py input/jobs.csv --execute --journal output/batch.json

Inspect rows, missingJobIds, and runStatus in the journal. The runner requests a $0.05 pay-per-event ceiling and a 180-second Actor timeout; platform charges are separate. It preserves validated partial rows without calling the batch successful. If a run ID was saved, recover a lost polling or download connection with --resume in place of --execute. If no run ID was received, inspect Apify Console manually and keep the journal. Never delete it just to repeat a paid request.

Send the first API request

The Actor name uses a tilde between owner and Actor. This request starts a run and returns a run object without waiting for completion:

curl -X POST \
  "https://api.apify.com/v2/actors/neuton~linkedin-jobs-search-scraper/runs" \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "queries": ["machine learning engineer"],
    "locations": ["United States"],
    "includeDescriptions": true,
    "maxResultsPerQuery": 25
  }'

Keep the returned run ID and defaultDatasetId. Poll the run endpoint until its status is terminal. Retrieve dataset items only after SUCCEEDED; treat FAILED, ABORTED, and TIMED-OUT as errors rather than empty demand.

Retrieve and validate the dataset

Read items from /v2/datasets/{defaultDatasetId}/items. Use clean=true when you want a cleaner export. Validate the response before inserting it into a CRM or warehouse:

1. Reject diagnostic rows from business tables.
2. Deduplicate by stable jobId, retaining the most recent source timestamp.
3. Keep jobUrl for auditability.
4. Do not interpret a missing description, salary, or seniority as a negative value.
5. Record the exact input and run ID beside the imported batch.

See the official Apify Run Actors guide and Run Actor API reference for current endpoint options.

Production checklist

• Use a server-side client, queue worker, or trusted automation platform.
• Set a timeout in your own poller and use bounded retry delays.
• Do not submit another run merely because the status is still running.
• Store run ID, dataset ID, input hash, and import timestamp.
• Use webhooks when polling is wasteful, and make the receiving endpoint idempotent because webhook delivery can repeat.
• Use a saved Task when several systems must share the same reviewed input.

Control cost before scale

The broad Jobs Search workflow is currently $0.34 per 1,000 returned rows in the local catalog. The live Apify Pricing tab is authoritative. Start with 25 rows, inspect the dataset, then increase one dimension at a time. More keywords multiplied by more locations create more searches. Use specialist Actors only when their evidence-backed output removes analysis you would otherwise build yourself.