Dice Jobs Scraper

This Dice scraper turns dice.com search results into a clean dataset of tech job listings, by keyword and location. Give it a list of search terms and you get back one row per job: title, company, location, how long ago it was posted, and a direct link, ready for hiring-market tracking, recruiting and salary research.

Dice is a specialist board rather than a general one, so the results skew heavily toward software, data, infrastructure and security roles, including a large volume of contract and staffing-agency work that does not appear on consumer job sites. If you search Dice tech jobs by hand every week, this actor does the same search for you and keeps every row.

How to use the Dice Jobs Scraper

1. Enter one or more search terms, such as python developer or kubernetes.
2. Set a location, or leave it empty to search everywhere.
3. Choose how many result pages to read per search term.
4. Start the run and download the jobs as JSON, CSV or Excel, or read them through the Apify API.

Input

field	type	default	what it does
queries	list of strings	none	Search terms: job titles, skills or technologies. A comma-separated string also works. A full Dice search URL is used exactly as pasted, which is the escape hatch for filters this form does not expose.
location	string	Remote	City, state or Remote; empty means everywhere. Dice treats Remote as a place name, so results are not limited to remote jobs; filter on is_remote for that.
pages	integer	1	Result pages per search term (1 to 20). Each page holds roughly 30 to 34 jobs.
jobs_per_query	integer	500	Maximum jobs kept from each result page (1 to 5000).
max_queries	integer	30	Maximum number of search terms per run (1 to 200).
concurrency	integer	4	Pages read in parallel (1 to 12). Does not change the output.
retries	integer	3	Attempts per page (1 to 8).
country	string	none	Optional two-letter country code to request the pages from, such as us.

Example input:

{
  "queries": ["kubernetes"],
  "location": "Austin, TX"
}

What each job gives you

• title and url, a direct link to the listing
• company, which on Dice is often the staffing agency rather than the end client. That is how Dice publishes it, and inventing an end client we cannot see would be worse than reporting what is there.
• location, and is_remote derived from it
• posted, exactly as Dice wrote it (Today, 2d ago, 21d ago)
• posted_days_ago, that same age converted to a number so you can filter and sort on it
• query and page, so every row traces back to the search that found it

Both forms of the date are kept on purpose. The number is what you filter on; the original text is what lets you check the number.

Two details that decide whether the output is right

Location and posted date share one element. A Dice card renders McLean, Virginia • Today as a single line, separated by a bullet. Split it wrong and your location column reads Virginia • Today, which sorts, groups and filters badly while looking almost correct. The two halves are separated properly, and a card that carries only a date is not mistaken for a card that carries only a location.

Dice abbreviates its dates. The page says 21d ago, not 21 days ago. A date parser written for the long form matches nothing and quietly returns a null day count for every job older than today, which makes a run look far fresher than it is. Both the abbreviated and long forms are handled, and a date that cannot be read is reported as unknown rather than as zero days, because zero would mean "posted today".

How the fields are found

Every field is read through Dice's own data-testid attributes rather than through styling classes. Those attributes exist for Dice's internal test suite and change far less often than the utility classes wrapped around them, so this survives a visual redesign that would break a class-based parser.

Run summary

Jobs returned, how many carried a company, how many carried a location, how many are remote, the number of unique companies, and counts of listings posted today and within the last week.

Those last two are the useful ones for a recurring run: a search that returns the same 60 jobs every day with none posted this week is telling you the market is quiet, not that the actor is broken.

Scale and deduplication

Each result page costs exactly one fetch. Two search terms at one page each returned 67 jobs in the recorded run on 4 October 2026. The number can change as listings are added or expire.

Rows are deduplicated on Dice's job identifier across every term and page in one run, so searching python developer and python engineer together gives you the union rather than a pile of duplicates. The identifier is stable, so deduplicating across separate runs works the same way.

What people use this for

Hiring-market tracking. Run a fixed set of search terms weekly and keep the rows. Because job ids are stable and posted_days_ago is a number, you can measure how many genuinely new listings appear per week per skill, which is a far better demand signal than a total result count that includes months-old postings.

Skill demand comparison. Search several technologies in one run and compare unique company counts rather than raw job counts. One agency posting the same role forty times inflates the second number and not the first.

Agency versus direct hiring. Dice carries a lot of staffing-agency listings alongside direct employers. Grouping by company shows the split immediately, which matters if you are a candidate deciding where to spend effort or a recruiter sizing the competition.

Location analysis. Pairing the same search term across several locations, including Remote, shows where a skill is actually being hired for rather than where people assume it is.

Notes

Dice cards publish relative dates, so posted_days_ago is accurate to the day rather than the hour. A job showing 5h ago is reported as 0 days. When the listing publishes a full timestamp, the additional posted_at field preserves it.

Listings that are filled or expire stop appearing in results. Running the same searches on a schedule and keeping the rows gives you both a hiring-volume trend and a read on how long postings stay open.

No login, no cookies and no API key are needed.

Output: Dice job listings as JSON or CSV

A real row from the run above (kubernetes in Austin, TX, 4 October 2026):

{
  "job_id": "111b155a-1c6f-4afb-8b4e-b6870f63721a",
  "internal_id": "89643b226a0f5cd89417952f48d4f3a5",
  "title": "Lead Data Software Engineer with Databricks with Apache Kafka, Apache Spark, Kubernetes",
  "url": "https://www.dice.com/job-detail/111b155a-1c6f-4afb-8b4e-b6870f63721a",
  "company": "EPAM Systems",
  "location": "Remote",
  "is_remote": true,
  "posted": "Today",
  "posted_days_ago": 0,
  "query": "kubernetes",
  "page": 1,
  "position": 2,
  "source": "dice-scraper",
  "platform": "dice",
  "fetched_at": "2026-10-04T09:18:35.654Z",
  "city": null,
  "state": null,
  "country_code": null,
  "posted_at": "2026-10-03T09:55:08Z",
  "modified_at": "2026-10-03T21:10:02Z",
  "employment_type": "FULL_TIME",
  "salary": null,
  "employment_type_text": "Full-time",
  "employer_type": "Direct Hire",
  "easy_apply": false,
  "workplace_types": [
    "Remote"
  ],
  "summary": "We are looking for a Lead Data Software Engineer to drive the migration of an existing data analytics platform, originally built on Azure resources such as Data Factory, Databricks, Event Hub, and Cassandra, to a cloud-agnostic platform deployable on-premises. Responsibilities Implement streaming and batch Spark pipelines running on Kubernetes Lead the implementation of objects within the data generator framework Oversee deployment and testing across local and development environments Drive impr",
  "company_logo_url": "https://d3qscgr6xsioh.cloudfront.net/crZDVk3SaOSmJtnU4MXw_376bd6a5038e7b330e660071c3902f10.png?format=webp",
  "company_profile_id": "940d3f7c-fdb2-5460-90ee-763066097138"
}

The first twelve fields (job_id to position) are the original output and keep their original types. The rest are additional fields, described below.

Additional output fields

The original card fields remain available with their original JSON types. Public listing data additionally provides:

• posted_at and modified_at, the source timestamps; posted keeps the card's relative date
• city, state and country_code
• employment_type (such as FULL_TIME or CONTRACTOR) and employment_type_text (Full-time, Contract)
• employer_type (Direct Hire or Recruiter), easy_apply and workplace_types (Remote, Hybrid, On-Site)
• salary, the advertised pay text exactly as published, without inferring a currency, hourly rate or annual amount
• summary, a short teaser of the job description, not the complete text
• company_logo_url and company_profile_id
• source, platform and fetched_at, so rows from several job boards can be combined

These fields are null when Dice does not publish them.

Dice scraper compared with the alternatives

Searching Dice by hand. Fine for one search, but there is no export, and comparing skills, cities or weeks means copying rows into a spreadsheet.

The Dice API. Dice offers integrations for employers and hiring partners to post and manage their own jobs. There is no public search API that returns job listings for market research. (Searches for "Dice API" also turn up the API of the unrelated Dice events and ticketing app.)

Writing your own scraper. Possible, but you have to keep up with page changes, split location from date correctly, parse abbreviated dates and deduplicate across pages. This actor does all of that and keeps its output stable.

Other Dice actors in the Store. Most charge per result as well. This one returns both the original relative date and a numeric day count, keeps the staffing agency as published, and adds salary text, employment type and employer type when Dice provides them.

Pricing

The price is pay per event:

event	price	when
Actor run started	$0.001	once per run, also when a search returns no jobs or no search term was provided
Job listing	$0.002	per delivered job row

Examples from real runs:

• kubernetes in Austin, TX, one page: 32 jobs, $0.001 + 32 × $0.002 = $0.065
• python developer and data engineer, one page each: about 65 jobs, roughly $0.13
• 1,000 jobs cost $2.00 plus the $0.001 start fee

An empty dataset has no job events. Duplicate job identifiers within a run are delivered and counted once. Free-plan users receive at most 10 job rows per run, while the run summary still describes the complete search.

FAQ

Is it legal to scrape Dice? The actor reads only public search result pages that anyone can open without an account. It collects no personal data beyond what employers publish in their listings. Check your own use against the laws and terms that apply to you.

Do I need a Dice account, cookies or an API key? No. No login, no cookies and no API key are needed.

Why is the company sometimes a staffing agency? That is how Dice publishes the listing. employer_type tells you whether the poster is a recruiter or a direct employer.

Does location: Remote return only remote jobs? No. Dice reads it as a place name. Filter on is_remote or workplace_types for remote work.

How many jobs can one run return? Up to 20 pages per search term and 200 search terms per run, at roughly 30 to 34 jobs per page, deduplicated across the whole run.

Why is posted_days_ago null for some jobs? Dice shows 30+d ago for older listings, which is not an exact age. Use posted_at for the exact timestamp when it is present.

Can I schedule it? Yes. Use Apify schedules to run the same searches daily or weekly and compare the job ids between runs.