LinkedIn Jobs Scraper

When to use it

Build a daily alert for a client, keep a job board supplied with records, or track which employers are advertising roles in your market. Each record keeps the original link and source identity. This collects job postings; it is not a candidate-contact database.

• Search by keyword, location, recency, work arrangement, and supported LinkedIn-specific filters.
• Enable cross-run deduplication to skip postings previously returned for the same workflow. Keep a stable scope for that alert or tracker.
• Enable company data, AI enrichment, translation, raw descriptions, or analytics only when the downstream use requires them.

Try a five-job search

Open this tool on Apify ↗, sign in, and paste the example below into the Input JSON editor. Set a maximum run cost before starting.

Start with five rows, a specific location and time window, and optional paid or stateful features disabled. The run-level charge cap belongs in the Apify API or integration caller, not inside this JSON.

{
  "schemaVersion": "nomad-agent-job-search-input-v1",
  "keyword": "TypeScript developer",
  "location": "Spain",
  "postedWithin": "7d",
  "workArrangements": ["remote", "hybrid"],
  "maxItems": 5,
  "translateToEnglish": false,
  "aiEnrichment": { "enabled": false },
  "includeRaw": false,
  "dedupe": { "enabled": false },
  "analyticsEnabled": false
}

What a small run costs

Base results cost $0.90 per 1,000 jobs: 100 base results cost $0.09 in Actor result charges. Five base results cost $0.0045. AI enrichment, translation, and applicable platform costs are additional.

Prices checked 6 September 2026. Check current Apify pricing and set a maximum run cost.

For developers: the job record

Each row uses exactly schemaVersion, identity, data, custom, llm, and raw at the root. Derive jobKey = source:externalId for destination upserts. A title, company name, or URL can change and is not stable identity.

Keep the canonical record when downstream logic needs nested requirements, hiring contacts, source provenance, raw descriptions, or the distinction between null and []. The 32-field flat projection is a destination convenience and deliberately loses nested detail.

Exact-run completion checklist

The current default build API returns the default build number and immutable build ID. Maintained integrations select latest. Record each run’s resolved numeric build number and immutable ID, then validate its summary and dataset before delivery.

1. Select latest and set a conservative item and maximum charge cap.
2. Retain the returned run ID and poll that exact run to a terminal status.
3. Require SUCCEEDED, the requested build, and a valid nomad-agent-run-summary-v4 from the same run’s key-value store.
4. Honor no more than one retry, and only when a usable partial summary explicitly recommends it.
5. Fetch the same run’s default dataset and require its complete row count to equal RUN-SUMMARY.delivered.
6. Validate all six roots and identity.source = linkedin before delivery.

Troubleshooting

• Zero rows: require a validated empty summary before calling the search clean; an invalid summary or blocked extraction is not “no matching jobs.”
• Repeated rows: keep one stable opaque dedupe scope across scheduled calls, and still upsert by jobKey at the destination.
• Missing descriptions: check the source record and selected raw/enrichment options; never manufacture evidence from the title.
• Wrong fields: confirm the requested build, exact input schema, and canonical dataset before changing a mapper.