Dice Jobs Lookup — Tech Job Postings by Keyword & Location

You write job searches the way you'd type them into Dice — python @ Austin — and this actor runs each one against Dice.com's own search-results pages, one of the largest dedicated tech job boards in the US, and returns one clean row per posting: title, company, location, employment type, pay range (when Dice shows one), and a permanent link.

No login. No API key. No proxy. Dice's search page is fully server-rendered HTML — this reads it directly, the same page a browser would load.

Who it's for

A recruiter or staffing desk sourcing tech roles wants a live feed of what's actually open right now, by skill and by city, without clicking through Dice's own results page by hand. A sales or BI-tooling vendor selling into tech-hiring teams wants a signal of who's actively hiring for a given stack, at scale, across many searches at once. Both get the same shape here: paste a list of "keyword @ location" searches, get back a flat row per posting, and pay only for postings actually returned — a search that finds nothing costs nothing.

This actor is the tech-hiring-focused counterpart to seek-jobs-search-lookup (Australia, general) and stepstone-jobs-lookup (DACH region, general): wide-net keyword + location search rather than a per-company listing. The ATS lookups in the same family (greenhouse-jobs-lookup, lever-jobs-lookup and friends) answer "what is this company hiring for" — you bring the company list. This one answers "who is hiring for this stack, in this city" when you don't have the list yet.

Why this one

• Reads the page Dice itself renders — no reverse-engineered API to keep working. Dice's search-results page (dice.com/jobs?q=...&location=...) returns the full job list as server-rendered HTML on the very first response, no client-side fetch required. A guessed separate JSON backend (a job-search-api.svc.dice.com-shaped hostname) does not resolve publicly — it's an internal service name, not a public endpoint — but it was never needed: the search page's own HTML already has everything.
• Real pagination, confirmed, not assumed. ?page=2 returns a fully disjoint set of postings from ?page=1, and even ?page=99 on a ~1,700-result search returned a further disjoint set — Dice showed no hard depth ceiling in this actor's testing, unlike SEEK's ~500-result or LinkedIn's ~1,000-result caps on the portfolio's other search-shaped job-board actors.
• Filters out Dice's own "similar jobs" noise. The tail of a results page carries a few recommendation-widget cards that reuse the same card markup as real results but strip out company, location, and posted-date — this actor recognizes and drops those before they ever reach you, rather than returning a degraded, half-empty row.
• You are never billed for the same posting twice. Every posting is deduplicated by its Dice job ID across the pages of one search and, by default, across every search in the run — an overlapping pair of searches returns, and bills, each posting once.
• Honest about what's NOT here. The search card itself carries no description or summary text of any kind — title, company, location line, and two optional chips (employment type, salary) are everything Dice puts there. Fetching each posting's own detail page would double the request cost for a field this actor can't confirm is worth that, so description is always empty here rather than a placeholder guess. If you need the full posting text, follow url to Dice yourself for postings you've already shortlisted.
• postedAt is a best-effort date, not a timestamp. Dice's own card only ever says "Today" or "Nd ago" — no time of day, no absolute date anywhere on the card. postedAt converts that to an ISO date relative to when this actor ran; postedAgo carries Dice's own original wording alongside it so you can see exactly what that conversion was based on.

What you get

One row per job posting by default. (Turn off "One row per job posting" in the Input tab to get one row per search instead, with the whole posting list nested in jobs.) Every row carries these fields:

Field	Type / format	Description
query	text	The search line you passed in, unchanged.
found	boolean	true if the search returned at least one posting. false rows are never charged.
status	text	OK, NOT_FOUND (no postings for that search), BAD_FORMAT (the line had neither keywords nor a location), or BLOCKED.
searchKeywords	text	The keywords actually sent to Dice.
searchLocation	text	The location actually sent to Dice.
jobCount	number	How many postings this search returned after your filters — this is exactly what you're charged for.
totalAvailable	number	Dice's own total-match count for the search, before this actor's page/depth limits. Can drift slightly between requests to the same search — Dice's own index is live and churning.
truncated	boolean	true if more postings were available than you asked for, or if paging stopped early (a mid-run rate limit).
jobs	array	The full posting list. Present in every row; it's what gets expanded into separate rows in "one row per posting" mode.
jobId	text	Dice's own posting UUID — stable, and what deduplication keys on.
title	text	Job title.
company	text	Hiring company as Dice names it.
location	text	Location as Dice prints it on the card — a bare "City, State" (onsite), "Hybrid in City, State", or exactly "Remote".
remote	boolean	true if the location or title reads as remote.
employmentType	text	e.g. "Full-time", when Dice shows a chip for it.
salaryText	text	The pay range or rate exactly as Dice's chip shows it (e.g. "$149,000 - $166,000"). Present only when Dice has an estimate or listed range for this posting — roughly half of postings in this actor's testing.
postedAt	date (ISO)	Best-effort conversion of Dice's relative posted-ago text to an absolute date. Day precision only — see "Why this one" above.
postedAgo	text	Dice's own words for the same thing ("Today", "21d ago").
url	link	Permanent link to the posting on dice.com.
description	text	Always empty — Dice's search card carries no description text (see "Why this one"). Kept as a column for schema consistency with this portfolio's other search-shaped job-board actors.
scrapedAt	date (ISO)	When this actor fetched the row.

A search that returns no postings comes back as a single found: false row with a status/message explaining why, and is never charged. So does a blank line.

Pricing

Pay-per-event, per job posting returned:

• Job posting returned: $1 per 1,000 job postings, less on paid Apify plans.

Plus a $0.00005 start fee per run. Misses (found: false) are never charged.

You're charged per posting returned, not per search — a search that returns 12 postings costs twelve, a search that returns none costs nothing, and a BAD_FORMAT line costs nothing.

1,000 postings through this actor: ~$1.00 if every search finds results, less on a paid Apify plan. Because you pay per posting, "Most postings to return per search" is your budget control: leave it at 50 and a ten-search run costs at most 500 postings' worth.

How to use

1. In the Apify Console. Open the actor page and click Start — the searches field is already pre-filled with a working example. Results land in the run's dataset as soon as each item is found.
2. Via the API. Call it directly with a POST request — no Console needed once you have an API token:

   curl "https://api.apify.com/v2/acts/accountable_eel~dice-jobs-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
     -X POST \
     -H "Content-Type: application/json" \
     -d '{"searches":["python @ Austin"]}'
   

3. On a schedule. Save this actor as an Apify Task with the input you want, then add a Schedule (hourly, daily, weekly) so it runs on its own — no server of your own required.

Paste one search per line:

python @ Austin
network engineer
java developer @ Remote

A line with no @ location uses the location you set once in 🔍 Search settings — leave that blank too and the search covers the whole of Dice's US listings.

🔍 Search settings:

Input	What it does
defaultLocation	Location for any line that doesn't name one. Write it as Dice does — a city and state, or "Remote".
maxJobsPerQuery	Most postings to return per search. Default 50.

🎯 Narrow the results — applied here, to the postings after they arrive. They combine with AND across fields and OR within a field:

Input	What it does
titleKeywords	Keep only titles containing one of these — ["engineer","data scientist"].
excludeTitleKeywords	Drop titles containing one of these — ["intern","trainee"]. Applied after the include list.
companies	Keep only these companies — partial names match.
excludeCompanies	Drop these companies — useful for filtering out recruitment agencies you already know.
locations	Narrow a wide search to particular cities or states.
remoteOnly	Keep only roles whose location or title reads as remote.
skipDuplicateJobs	On by default. Each posting is returned, and billed, once per run even if two searches overlap.

Input

{
  "searches": [
    "python @ Austin"
  ]
}

One search per line. Write it as "keywords @ location", or just the keywords and set a location below. Accepted formats: python @ Austin, network engineer, java developer @ Remote.

Output

Populated with a real captured row once this actor's first live run completes — see the build handoff (docs/eval/builds/dice-jobs-lookup.md) for the verbatim first output row from that run until this section is regenerated from a canary.

A miss comes back as a row with "found": false and is never charged.

Use it from Clay, n8n, Make, or an AI agent

This actor runs synchronously over plain HTTP — call it directly from a script, a workflow tool, or an AI agent, no Apify Console needed once you have an API token.

curl "https://api.apify.com/v2/acts/accountable_eel~dice-jobs-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"searches":["python @ Austin"]}'

n8n. Add an HTTP Request node: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~dice-jobs-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body Content Type JSON, JSON Body {"searches":["python @ Austin"]} (swap in an expression from an earlier node for a real value).

Clay. Add an "HTTP API" column: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~dice-jobs-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body {"searches":["{{search}}"]}, mapping the row's search into the searches array.

MCP. In Claude, Cursor, or any MCP client with the Apify MCP server, ask for "Dice Jobs Lookup | Apify" — the agent will find and run this actor.

Tips

• Run "Try it first" on a handful of searches you already know return results for, to sanity-check the shape before spending on a full list.
• Keep maxJobsPerQuery modest (the default 50 is a sensible ceiling) — you pay per posting returned, so a broad nationwide keyword search with no location can otherwise return far more rows than a narrower one, at proportionally higher cost.
• Use titleKeywords/excludeTitleKeywords rather than cramming everything into the search line itself — Dice's own search box does simple keyword matching, and this actor's post-filters give you AND/OR control Dice's search box doesn't.
• remoteOnly is a strong filter, not a guarantee — it only catches roles whose location or title actually reads as remote in Dice's own text. A role that's remote-friendly but posted with an onsite city and no mention of "remote" won't be caught.
• If you need more than a card's worth of description, url links straight to the posting on dice.com for anything you've shortlisted — this actor doesn't fetch that page itself (see "Why this one").

vs. alternatives

	What it costs	What you get	Trade-off
This actor (dice-jobs-lookup)	$0.001 per posting returned (less on paid Apify plans), $0.00005 actor start, nothing for a search that finds nothing	One row per Dice posting — title, company, location, employment type, pay range (when listed), and link — filtered by title keyword, company, location, or remote-only	Tech-focused Dice listings only, US-centric. No description/summary field — Dice's own card carries none, and this actor doesn't fetch the detail page (see "Why this one").
TheirStack	$0.005–$0.03 per company	A job-postings dataset with history, normalised across many ATS platforms and job boards	Broader coverage across many sources, and it keeps history. This reads Dice's own search page live, at a fraction of that price per row.
shahidirfan/Dice-Job-Scraper	Pay-per-result on Apify (167 u30, rated 5.00 on 3 reviews)	Also scrapes Dice search results	A thin review base (3 reviews) to judge reliability against. This actor prices per posting rather than a flat run fee, dedupes across overlapping searches, and filters out Dice's own "similar jobs" widget noise before it reaches you.
Doing it yourself	Your time + tracking Dice's own markup as it changes, handling pagination, and filtering the recommendation-widget cards out by hand	The same data	The card parsing, pagination, dedup, and widget-noise filtering this actor already does are the maintenance burden it absorbs.

Prices for third-party tools are their published figures as of September 2026 and are not tracked here — check the vendor before relying on the comparison.

FAQ

Why is a row empty, or why does found say false? Either the input line has neither keywords nor a location (status: BAD_FORMAT), Dice blocked the request (status: BLOCKED, HTTP 403/429/503), the request failed after retries (status: REQUEST_FAILED), or the search genuinely has no matching postings right now (status: NOT_FOUND). Check the message column for the specific reason. None of these are billed.

Am I charged for a miss? No. You're only charged for postings actually returned. A blocked search, a search with zero matches, or a malformed input line all produce a row (unless you turn on "Hide rows with no result") and none of them cost anything.

Is postedAt an exact timestamp? No — it's a best-effort date. Dice's own card only ever says "Today" or "Nd ago", with no time of day and no absolute date anywhere on the card, so postedAt is that relative phrase converted to an ISO date at the time this actor ran. postedAgo carries Dice's original wording alongside it so you can see exactly what the conversion was based on.

Why is description always empty? Dice's search-results card carries no description or summary text at all — title, company, location line, and two optional chips (employment type, salary) are everything present. Fetching each posting's own detail page for a longer description would double the request cost (and the bill) for a field this actor can't confirm is worth that trade-off — see "Why this one". Follow url to the posting on dice.com if you need the full text for a shortlisted role.

Does this handle Dice's own "similar jobs" recommendation cards? Yes — those are recognized and dropped before they reach you. They reuse the same card markup as real search results but carry no company, location, or posted-date, sometimes echoing the same job ID as an earlier real result on the same page.

Do I need to configure proxies? No. Dice's search page is not behind a bot wall in this actor's testing — plain requests through Apify's default proxy configuration work fine.

Can I schedule this to re-check the same searches on a cadence? Yes — set up an Apify Task with a schedule (daily, weekly, whatever cadence fits) and point it at this actor with a saved input. Each run is a fresh fetch against Dice's live listings.

Can an AI agent call this directly? Yes. It's registered on the Apify MCP server — an agent in Claude, Cursor, or another MCP client can find and run it by name ("Dice Jobs Lookup | Apify"), or you can call the REST endpoint shown above from any script or workflow tool.

Related actors

• SEEK Jobs Search Lookup — the same keyword + location search shape, for Australia's largest general job board.
• StepStone Jobs Lookup — the same shape again, for the DACH region.
• ATS Jobs Unified Lookup — once you have a specific company in mind rather than a keyword search, pull its open postings directly from its own ATS.