How to monitor new jobs in Norway automatically

#apify #automation #career #api

A job search is useful once. A repeatable job monitor is useful every morning, without asking a human to remember which listings were already reviewed.

The Norway Jobs Search API has a monitor mode. It compares the normalized, deduplicated job set against persistent state and can emit NEW, UPDATED, REAPPEARED, and conservative REPOSTED rows. It does not turn a schedule into an uncontrolled crawl: source pagination and final result count remain bounded by the input.

1. Define one stable watch

This example looks for new or changed data roles around Bergen. The stable stateKey lets repeated runs share the same history.

{
  "query": "data analyst",
  "locations": ["Bergen"],
  "radiusKm": 40,
  "publishedWithinDays": 14,
  "sources": ["jobbnorge", "linkedin"],
  "remote": "ANY",
  "maxResults": 25,
  "sortBy": "publishedAt",
  "mode": "monitor",
  "stateKey": "bergen-data-analyst-watch",
  "emitUnchanged": false
}

When stateKey is omitted, the Actor derives one from the normalized search configuration. An explicit key is easier to recognize when a team has several scheduled watches. Do not overlap two runs that use the same key.

2. Schedule the existing task

Save no new configuration unless the existing Task is missing. Attach the matching published Task to an Apify schedule and send completed-run data to the destination your workflow already uses. The Actor’s persistent state makes subsequent runs incremental; the first run establishes the initial set.

3. Route only changes downstream

A representative monitoring row looks like this:

{
  "canonicalJobId": "job_4c6e_example",
  "title": "Data Analyst",
  "company": "Example AS",
  "publishedAt": "2026-08-31T07:30:00.000Z",
  "applyUrl": "https://jobs.example.invalid/456",
  "matchScore": 84,
  "changeType": "UPDATED",
  "changedFields": ["description", "deadline"],
  "firstSeenAt": "2026-08-28T08:00:00.000Z",
  "lastSeenAt": "2026-09-01T08:00:00.000Z"
}

Use canonicalJobId, changeType, and timestamps as idempotency fields in the downstream workflow. The Actor documents at-least-once delivery around a crash between Dataset push and saved monitor acknowledgement, so consumers should tolerate a repeated row.

Cost

The current Store price is a $0.00005 start event plus $0.0025 per final unique job row. Monitoring does not add a separate custom charge for raw candidates, filtered vacancies, or duplicate portal listings.

Try it

Use the existing published Norway jobs monitoring Task: Monitor new Norway jobs.

The Actor documentation explains source-specific limits, including the separate NAV feed token requirement.

DEV Community