DEV Community: Automation Helper

How to monitor brand mentions on Threads without a login

Automation Helper — Tue, 01 Sep 2026 18:47:43 +0000

Brand monitoring on Threads does not need to mean managing a browser profile or collecting private data. A useful baseline is a time-bounded feed of public profile posts and public keyword-search results, with duplicates removed before they reach a sheet, dashboard, or alert workflow.

The Threads Scraper has a monitor mode that combines those two sources. It requests public Threads pages using HTTP only and does not require a Threads login, cookies, browser automation, or private APIs. It is stateless: the caller supplies a since cutoff for each monitoring run.

1. Define the public watch

{
  "mode": "monitor",
  "usernames": ["examplebrand"],
  "queries": ["ExampleBrand", "Example Brand"],
  "since": "2026-09-01T00:00:00Z",
  "includeKeywords": ["ExampleBrand", "Example Brand"],
  "maxResults": 50,
  "sortBy": "newest"
}

At least one of usernames or queries is required. The post processing order is normalize, deduplicate, filter, sort, then truncate. It means maxResults caps final unique monitoring rows rather than a separate limit per source.

2. Advance `since` in the scheduler

The Actor does not save a hidden monitoring cursor. For a recurring integration, pass the last successful cutoff as since on the next run. This is deliberate: the calling workflow controls the time window and can replay a period if it needs to recover an alert destination.

3. Use provenance to understand why a post matched

{
  "id": "threads-post-example",
  "url": "https://www.threads.com/@example/post/EXAMPLE",
  "text": "Example public post text mentioning ExampleBrand.",
  "publishedAt": "2026-09-01T08:45:00.000Z",
  "likeCount": 12,
  "author": {
    "username": "public_author",
    "isVerified": false
  },
  "matchedProfiles": ["examplebrand"],
  "matchedQueries": ["ExampleBrand"],
  "sourceTypes": ["profile", "search"],
  "hashtags": [],
  "mentions": [],
  "scrapedAt": "2026-09-01T09:00:00.000Z"
}

Some public fields can be null when Threads does not expose them on the requested page. This is public-content monitoring, not access to private accounts, DMs, comments, replies, or a complete historical stream.

Cost

The current monitor result price is $0.002 per final unique monitoring row, plus a $0.00005 Actor start event. Duplicate, filtered, skipped, and empty results are not final result events. Recheck the pricing page when choosing the operational cap.

Try it

Use the existing brand-monitoring Task: Monitor Threads mentions.

See the Threads Scraper Actor page for the public-data scope and all monitor filters.

G2 review alerts: track new 1–3-star feedback across products

Automation Helper — Tue, 01 Sep 2026 18:33:05 +0000

“Review alert” should mean a small stream of new, actionable feedback—not a daily export of the same G2 page. For a SaaS team watching multiple products or competitors, the practical workflow is to store a fixed product list, choose the rating threshold, and only review additions.

The G2 Negative Review Monitor is designed for exactly that incremental path. It accepts several products in a single run, filters public G2 review RSS locally to the selected whole-star ratings, and retains stable review identifiers to remove repeats on later runs.

1. Use one multi-product input

{
  "products": [
    "https://www.g2.com/products/slack/reviews",
    "notion",
    "https://www.g2.com/products/hubspot-sales-hub/reviews.rss"
  ],
  "ratings": ["1", "2"]
}

This is appropriate for monitoring public feedback for named products. It does not claim to classify complaint themes, identify a customer, or infer why a reviewer may switch tools. If you need such interpretation, use the returned review text in a separate, policy-appropriate analysis step.

2. Send only new records to the alert destination

Use the Task Dataset or a finished-run webhook as the handoff. A review event contains the product, whole-star rating, text, source URL, and timestamps, so an alerting workflow can route 1-star reviews differently from 2-star reviews without guessing from prose.

{
  "product": "notion",
  "rating": 1,
  "title": "Example title",
  "review": "Example public feedback text.",
  "reviewId": "g2-review-example-456",
  "sourceUrl": "https://www.g2.com/products/notion/reviews",
  "publishedAt": "2026-09-01T08:00:00.000Z",
  "firstSeenAt": "2026-09-01T10:00:00.000Z"
}

3. Keep the operational expectation realistic

The initial check may yield every matching review currently visible in the RSS feed. That is the baseline. The useful alert stream starts on later runs, which return only unseen matching review IDs. The Actor’s state is kept per product and bounded, so it is not a general archive of every G2 review ever published.

Cost

Pricing is pay per successful product check: currently $0.0075 per successfully checked product, plus a $0.00005 Actor start event. A five-product daily watch therefore has an understandable upper bound before it runs.

Try it

Start from the existing multi-product alert Task: Run G2 review alerts.

The Actor page lists its public-RSS scope and supported ratings.

How to monitor new negative G2 reviews automatically

Automation Helper — Tue, 01 Sep 2026 18:32:25 +0000

Negative reviews are most useful close to publication, when a product, support, or competitive-research team can still see the pattern forming. Manually opening a handful of G2 pages every day is unreliable, and pulling the same historical review feed repeatedly creates noise.

The G2 Negative Review Monitor reads public G2 product review RSS feeds, locally filters the whole-star ratings you select, and remembers review IDs so later runs emit only newly seen matching reviews. It is built for scheduled monitoring, not bulk historical extraction.

1. Provide product slugs or public G2 review URLs

You can use bare slugs, product review URLs, or the public review RSS URLs. They are normalized to product slugs before the request.

{
  "products": ["slack", "notion"],
  "ratings": ["1", "2", "3"]
}

2. Run it on a schedule

Attach the matching existing Task to an hourly or daily Apify schedule. The first run returns currently visible matching reviews. Later successful runs keep a bounded per-product history and emit only new 1–3-star review IDs. A second unchanged run therefore returns no review rows.

3. Read structured feedback

Representative output uses a stable review ID and source link:

{
  "recordType": "REVIEW",
  "isReview": true,
  "product": "slack",
  "reviewId": "g2-review-example-123",
  "rating": 2,
  "title": "Example review title",
  "review": "Example normalized public review text.",
  "reviewer": "Public reviewer name when available",
  "publishedAt": "2026-09-01T09:15:00.000Z",
  "firstSeenAt": "2026-09-01T10:00:00.000Z",
  "sourceUrl": "https://www.g2.com/products/slack/reviews"
}

The Actor only uses public G2 RSS and does not require a browser session or proxy requests. Invalid products are logged rather than converted into fabricated review results.

Cost

The current price is a $0.00005 start event plus $0.0075 for each successfully checked G2 product. A product that cannot be validated is not counted as a successful product check. Verify the live pricing tab before production use.

Try it

Use the existing negative-review monitoring Task: Monitor new negative G2 reviews.

Read the G2 Negative Review Monitor Actor page for accepted input formats and monitoring behavior.

How to monitor new jobs in Norway automatically

Automation Helper — Tue, 01 Sep 2026 17:49:16 +0000

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.

How to search Norwegian jobs across Jobbnorge and LinkedIn with one API

Automation Helper — Tue, 01 Sep 2026 17:47:23 +0000

Searching for jobs in Norway gets awkward quickly when each source returns a different shape. A title can be formatted differently, location data can be incomplete, and the same vacancy may appear on more than one job board. If your workflow needs structured results rather than browser tabs, the useful unit is not “one source at a time”; it is one normalized, deduplicated job feed.

The Norway Jobs Search API searches Jobbnorge and LinkedIn Jobs in a single run by default. It normalizes the final matches into one schema, applies local filters, keeps source provenance, and conservatively deduplicates cross-source listings. NAV Arbeidsplassen is also available when its separate NAV_JOB_FEED_TOKEN has been configured; it is not silently used by the no-secret default.

1. Start with a bounded search

Create a run with a job query, locations, a freshness limit, and an intentionally small result cap while you test the integration:

{
  "query": "software developer",
  "locations": ["Oslo"],
  "publishedWithinDays": 7,
  "sources": ["jobbnorge", "linkedin"],
  "employmentTypes": ["FULL_TIME"],
  "maxResults": 25,
  "sortBy": "match",
  "mode": "search"
}

maxResults is the number of final canonical vacancies, not the number of raw rows fetched from each source. That matters when one employer has placed the same role on several portals.

2. Use the canonical record, not source-specific HTML

A representative result row has stable job and source fields, plus explainable matching metadata:

{
  "canonicalJobId": "job_2bd71d_example",
  "title": "Software Developer",
  "company": "Example AS",
  "location": {
    "displayName": "Oslo, Norway",
    "city": "Oslo",
    "countryCode": "NO",
    "distanceKm": null
  },
  "publishedAt": "2026-08-30T09:00:00.000Z",
  "employmentType": "FULL_TIME",
  "workArrangement": "HYBRID",
  "applyUrl": "https://jobs.example.invalid/vacancy/123",
  "matchScore": 89,
  "matchReasons": ["Strong title match", "Published 2 days ago"],
  "sourceCount": 2,
  "canonicalSource": "jobbnorge",
  "changeType": "NEW",
  "sources": [
    { "source": "jobbnorge", "sourceId": "example-1", "url": "https://www.jobbnorge.no/..." },
    { "source": "linkedin", "sourceId": "example-2", "url": "https://www.linkedin.com/jobs/view/..." }
  ]
}

The exact fields vary when a source does not expose something. The Actor returns null instead of inventing salary, coordinates, deadlines, or a work arrangement.

3. Choose the integration surface that fits your workflow

In the Apify Console, use the Dataset as your JSON/CSV result set. For an application, call the Actor through Apify’s REST API or client, wait for the run, and read the default Dataset. The relevant part is to treat canonicalJobId as the identity and the nested sources array as audit provenance.

Cost

At publication time, the Actor has a $0.00005 start event and charges $0.0025 for each final normalized, deduplicated job row. Filtered rows and duplicate source listings are not the final result event. Check the Actor pricing page before a production rollout because Store prices can change.

Try it

Start from the existing no-secret Jobbnorge + LinkedIn task: Run the Norway Jobs search Task.

For filtering details and API context, see the Norway Jobs Search API Actor page.

DEV Community: Automation Helper

How to monitor brand mentions on Threads without a login

1. Define the public watch

2. Advance since in the scheduler

3. Use provenance to understand why a post matched

Cost

Try it

G2 review alerts: track new 1–3-star feedback across products

1. Use one multi-product input

2. Send only new records to the alert destination

3. Keep the operational expectation realistic

Cost

Try it

How to monitor new negative G2 reviews automatically

1. Provide product slugs or public G2 review URLs

2. Run it on a schedule

3. Read structured feedback

Cost

Try it

How to monitor new jobs in Norway automatically

1. Define one stable watch

2. Schedule the existing task

3. Route only changes downstream

Cost

Try it

How to search Norwegian jobs across Jobbnorge and LinkedIn with one API

1. Start with a bounded search

2. Use the canonical record, not source-specific HTML

3. Choose the integration surface that fits your workflow

Cost

Try it

2. Advance `since` in the scheduler