How to Get Job Postings from Indeed at Scale

Indeed is the widest net in job-market data — every employer size, every industry, posted directly or aggregated from a company's own careers page. That breadth is exactly what makes it useful for broad market research: a staffing agency scoping demand across a metro area, a job board pulling in listings by category, or a labor-market analyst tracking a role type across employers, rather than watching one named company at a time.

If you're an agent (or building one) reading this rather than a human, the full machine-readable schema for every endpoint below lives at mindcase.co/skills.md.

What makes Indeed useful for job-market research at scale?

Two things past the raw listing count:

• Real hiring-demand fields, not inferred ones. numberOfHires, employerResponsive, employerResponseRate, employerAvgResponseTimeDays, urgentHire, and highVolumeHiring are fields Indeed itself sets on the listing — you're reading a platform signal, not guessing from posting volume.
• A direct-lookup mode alongside search. Most job APIs only search. Indeed Jobs also takes specific job IDs directly, so a listing you discovered elsewhere (an alert, a partner feed) can be re-fetched for its full 48-field record without re-running the search that originally surfaced it.

How do you pull Indeed job listings?

Say you're scoping warehouse and logistics demand across Houston for a staffing agency — the same kind of search Indeed Jobs itself gives as a real example prompt.

How do you search by keyword and location?

curl -X POST "https://api.mindcase.co/v1/data/indeed/jobs/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "keyword": "warehouse associate",
    "location": "Houston, TX",
    "fromDays": 7,
    "maxItems": 50
  }
}'

# $0.00005 per job returned

Each row returns 48 fields: title, company, full address with latitude and longitude, salary range and currency, employment type, required skills and certifications, the full job description text, and the hiring-demand fields above. remote and jobType narrow further when you only want remote or contract roles, and country switches the search to any of 54 real Indeed country domains — default is US.

How do you look up specific jobs by ID?

If you already have Indeed job IDs — from an alert, a partner feed, or an earlier search — jobKeys fetches their full records directly, no keyword or location needed:

curl -X POST "https://api.mindcase.co/v1/data/indeed/jobs/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "jobKeys": ["a1b2c3d4e5f6g7h8", "h8g7f6e5d4c3b2a1"]
  }
}'

# $0.00005 per job returned

Same record shape either way — search and direct lookup return the identical 48 fields, so a pipeline built around the search response works unmodified on a jobKeys re-fetch.

What makes Indeed's hiring-signal fields different from other job boards?

employerResponsive, employerResponseRate, and employerAvgResponseTimeDays are specific to Indeed — neither LinkedIn Jobs nor Naukri Jobs returns an employer-responsiveness field. urgentHire and highVolumeHiring are the platform's own tags for demand spikes, not something you infer from posting count. Filtering a broad Houston pull down to rows where highVolumeHiring is true, or sorting by employerAvgResponseTimeDays, separates real near-term demand from listings that have been sitting open for months.

What can't you get from Mindcase?

Two cases.

You want to filter by a specific company. Indeed Jobs has no company-array field — keyword is the closest option, and a company name in the keyword can surface a posting that only mentions the company rather than one from it. If a named target list matters more than broad market coverage, LinkedIn Jobs takes a real company array of up to 10 names per call.

A trend line for hiring demand over time. Every field above reflects what's live right now — there's no "this metro's warehouse postings grew 20% this month" endpoint. Building that means running the same search on a schedule and storing each pull yourself.

Which endpoint should you use for which job?

How do you use this data responsibly?

Indeed listings are public by design — posted to attract applicants, not to stay private. The practical line: don't republish full listings as your own original content, attribute Indeed if you're building a public-facing aggregator, and treat employerResponsive-style fields as demand signals rather than a basis for contacting an employer's staff directly.

FAQ