For remote-first engineering teams, job aggregators curating top remote developer boards, and recruitment tools targeting senior technical talent — WWR's 5M+ monthly visitors signal a high-intent audience.

Pricing: $1.50/1,000 jobs — a single programming run (~25 jobs) costs ~$0.04

Scrape remote programming/developer job listings from WeWorkRemotely.com (5M+ monthly visits, one of the top remote job boards) using their official public RSS feeds. Returns structured job data with company, role, category, region, skills, and posting date.

Zero proxy cost — WWR publishes open RSS feeds with no authentication, no rate limits, and no access restrictions.

---

Features

• Programming jobs focus — Targets the dedicated programming feed by default
• Company/role split — Parses the "Company: Role" title format into separate fields
• Location enrichment — Combines state, country (emoji-stripped), and region into a single location field
• Full descriptions — Strips HTML to plain text; toggle off to reduce output size
• parse_confidence — Per-record quality score (0.0–1.0) that surfaces structural drift
• Keyword filter — Client-side title filter for targeted scrapes

---

Input

Field	Type	Default	Description
categories	string[]	["programming"]	Category keys to scrape. Default and prefill are ["programming"] to target remote programming/developer listings from WeWorkRemotely.com's official RSS feed.
keywords	string[]	[]	Case-insensitive keyword filter on job title. Empty = no filter
maxItems	integer	200	Max results total. 0 = unlimited
includeDescriptions	boolean	true	Include description_html and description_text

---

Output Schema (18 fields)

Field	Type	Description
job_id	string	URL slug — unique job identifier
title	string	Full "Company: Role" original title
company	string	Company name (before first : in title)
role	string	Job role (after first : in title)
category	string	WWR category, e.g. "Back-End Programming"
region	string	RSS region, e.g. "Anywhere in the World"
location	string	Best available: state → country → region
job_type	string	"Full-Time" / "Contract" / "Part-Time" / null
skills	string	Comma-separated skill tags or null
posted_at	string	ISO 8601 UTC post date
expires_at	string	ISO 8601 UTC expiry date (all-jobs feed only)
url	string	Canonical job page URL
description_html	string	Raw HTML description or null
description_text	string	Plain-text description or null
feed_type	string	"all_jobs" or "category"
feed_slug	string	RSS slug, e.g. "remote-programming-jobs"
parse_confidence	float	0.0–1.0 parse quality score
warnings	string[]	Machine-readable warning codes

---

Pricing example

Run	Jobs returned	Cost
Programming feed (~25 jobs)	~25	~$0.04

Pay Per Event — you only pay for results delivered.

Event	Rate / 1K	When charged
job-result	$1.50	Every job returned
category-filter	$1.50	Only when specific categories are specified (such as the default programming filter)

A targeted run for the programming category (~25 jobs) applies the category-filter rate and costs ~$0.04. Buyer compute included.

---

Output sample

{
  "job_id": "remote-jobs/1234567890",
  "title": "Acme Inc: Senior Backend Engineer",
  "company": "Acme Inc",
  "role": "Senior Backend Engineer",
  "category": "Back-End Programming",
  "region": "Anywhere in the World",
  "location": "Anywhere in the World",
  "job_type": "Full-Time",
  "skills": "ruby, rails, postgresql",
  "posted_at": "2026-06-01T00:00:00Z",
  "expires_at": "2026-07-01T00:00:00Z",
  "url": "https://weworkremotely.com/remote-jobs/1234567890",
  "feed_slug": "remote-programming-jobs",
  "parse_confidence": 1.0,
  "warnings": [],
  "scraped_at": "2026-06-05T10:00:00Z"
}

FAQ

Do I need an API key or proxy? No. WWR publishes open RSS feeds with no authentication, no rate limits, and no access restrictions.

What formats can I export? JSON, CSV, Excel, or JSONL — from the Apify dataset UI or REST API.

Why are job_type, skills, and expires_at null in some rows? These fields are only available in the all-jobs feed (categories: []). The default programming feed is lighter and faster but omits these fields.

What if the feed is unavailable? The actor logs the failure, skips it, and continues — no crash, no charge for the failed feed.

Notes

• RSS freshness — WWR feeds reflect current live listings. Listings stay active until expired or removed. No historical data.
• Null fields — job_type, skills, and expires_at are omitted in category feeds like the programming feed. They are only populated if you override the input to fetch the all-jobs feed (categories: []).
• Not affiliated with We Work Remotely. This actor accesses publicly available RSS data.

---

Use with AI agents (MCP)

This actor is available via Apify's MCP server. Connect it to any MCP-compatible agent (Claude, n8n, Make) to pull live WWR programming job data on demand — no code required.

https://mcp.apify.com/?tools=bovi/weworkremotely-programming-jobs

Vs. competitors

Feature	This actor	RemoteOK scraper	Generic RSS scrapers
Targeted programming feed	Yes	No (tag-based)	No
Company/Role split	Yes (parsed)	No	No
parse_confidence	Yes	Yes	No
Zero proxy	Yes	Yes	Yes
Price	$1.50/1K	$1.50/1K	Free (but raw)

For a broader remote job dataset with salary data, see our RemoteOK Scraper — pair both for full remote market coverage.

Integrations

Built for remote-hiring engineering teams and job aggregators tracking senior remote developer talent across WWR's top-tier job board — the JSON/dataset output drops into the tools you already run, no glue code:

• n8n / Make / Zapier — trigger a run or pipe every new dataset item into 500+ apps (Google Sheets, Airtable, Slack, HubSpot, your database) with no code: n8n, Make, Zapier.
• Webhooks — fire your own endpoint the moment a run finishes, to push results straight into your pipeline (docs).
• MCP server — expose this actor as a tool to Claude, Cursor, or any MCP client so an AI agent can pull this data mid-conversation (guide).
• API & SDKs — fetch the dataset as JSON, CSV, or Excel through the Apify REST API or the Python / JS SDKs.

See all Apify integrations.

Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as USAGE_STATS in your own Apify key-value store, so you can see the exact record created for your run.

Set disableUsageStats to true in the input to opt out. Nothing is sent then; your USAGE_STATS record only says that statistics were disabled.

Only these fields are recorded:

• schema version, Actor name and build number;
• UTC start and finish hour (not a precise timestamp);
• run duration, number of results and time to the first result, each as a coarse range;
• whether the result was empty, the end status, and an error type from a fixed list;
• memory setting and counts of charged events;
• names of the input fields you set, never their values;
• the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

Additional fields (Phase 2)

This Actor also records your Apify user ID, whether Apify marks the account as paying, the size range of list inputs, the selected country when the input offers a fixed list of countries, and one category from a fixed Actor taxonomy. We use these fields only for aggregate reliability, repeat-use and cross-Actor analysis; reports suppress any cell with fewer than five distinct users.

The same disableUsageStats: true input flag turns these fields off too. The user ID is removed after 13 months; we do not export, sell, share, or attempt to re-identify this data.

Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

• the result limit you asked for (a range, when the input has one) and what share of it was delivered;
• results delivered per input item you listed (a range);
• output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
• how the run was started (console, API, schedule, webhook, another Actor);
• how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
• if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
• a short code made from the names of the input fields you set, never their values.

Repeat-run fingerprint (v2)

When your Apify user ID is recorded (see above), the record also holds an 8-character one-way code made from your input (proxy settings left out) and this Actor's name. It only lets us see that the same account ran the same input again soon after an unsatisfying run; we never see the input itself. It is stored only in the database, never published, and reports use it in aggregate with the same five-user minimum. It is the one exception to the statement above that no hashes are collected, and disableUsageStats: true turns it off.