Mindcase for Talent and Hiring Research

Two other posts on this blog cover tracking hiring signals across a target list and alerting on new postings as they go live. Both answer the same underlying question: is this company hiring right now. This post answers a different one: if you're hiring for a role yourself, what should you actually pay for it, and what skills is everyone else asking for.

That's a market-rate question, not a signal question, and it means reading postings differently — not "is this new," but "what's the range across dozens of them, and what shows up in most of them."

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 does market-rate research actually require?

Pulling one job posting tells you what one employer is offering. It doesn't tell you whether that number is high, low, or normal. Getting a real range means pulling enough postings for the same role across enough sources that outliers wash out — which is exactly the kind of repetitive, multi-source pull an agent is better suited to than a person clicking through job boards one tab at a time.

How do you set up an agent to run this?

Point your agent at /skills.md once, then describe the role in plain language:

Set up mindcase.co/skills.md, then use Mindcase to benchmark the salary
range and required skills for a Senior Data Engineer role — pull postings
from LinkedIn, Indeed, and Naukri, and tell me the going rate and the
skills that show up most often.

An agent that's read the skills file already knows linkedin/jobs, indeed/jobs, and naukri/job each return salary fields alongside the posting, so it doesn't need you to name a single endpoint — it matches "benchmark salary and skills" to the job-board agents in the index and runs them.

What does the agent actually call, step by step?

Each job board exposes compensation differently, so the agent isn't running the same call three times with a different base URL — it's reading three different shapes of salary data.

How does it pull a salary-filtered slice from LinkedIn?

LinkedIn Jobs has a real salary filter — USD bands from 40k+ up to 200k+ — so the agent can narrow to postings in a plausible range before it even looks at the numbers each row returns:

curl -X POST "https://api.mindcase.co/v1/data/linkedin/jobs/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "jobTitles": "senior data engineer",
    "locations": "United States",
    "salary": ["120k+"],
    "employmentType": ["full-time"],
    "maxResults": 50
  }
}'

# $0.001 per job returned

Each row returns salaryMin, salaryMax, salaryCurrency, and salaryPeriod alongside 29 other fields — the agent can build a range straight from those without parsing free text.

How does it pull salary out of Indeed?

Indeed Jobs doesn't have a salary-band filter the way LinkedIn does, but every returned row carries the same shape of field — salaryMin, salaryMax, salaryCurrency, salaryPeriod, plus a raw salaryText string for postings where the structured fields don't fully capture a range (like "$120K - $150K + bonus"). It also returns skills per posting, which is what the agent uses to build the required-skills list, not just the salary range:

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": "senior data engineer",
    "location": "United States",
    "fromDays": 30
  }
}'

# $0.00005 per job returned

At $0.00005 per row, this is cheap enough for the agent to pull a wide sample — hundreds of postings — without the price becoming the limiting factor the way it might on LinkedIn.

How does it use Naukri's benchmark fields instead of raw postings?

This is the one real shortcut in the set. Naukri Jobs doesn't just return what one posting offers — it returns benchmarkRole, benchmarkMinCtcLakhs, benchmarkAvgCtcLakhs, benchmarkMaxCtcLakhs, and a benchmarkSalariesUrl, which is Naukri's own computed market range for that role, not a number the agent has to derive by averaging individual postings itself:

curl -X POST "https://api.mindcase.co/v1/data/naukri/job/run?wait=true" \
-H "Authorization: Bearer $MINDCASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "params": {
    "inputs": "data engineer",
    "cities": ["Bangalore"],
    "maxResults": 50
  }
}'

# $0.002 per job returned

For an India-market role, the agent can skip the averaging step entirely and read benchmarkAvgCtcLakhs directly — the other three job boards require building that number from a sample; Naukri hands it over pre-computed. The figure is in Lakhs per annum, not USD, so the agent still has to keep that unit straight against the other three sources rather than merging them into one number.

What does the finished benchmark actually look like?

The agent doesn't hand back four raw JSON dumps — it merges them into one answer: a salary range from LinkedIn and Indeed's structured fields, a comp band from Naukri's benchmark fields (kept separate, since it's in Lakhs and India-specific), and a ranked skill list built from how often each skill in Indeed's skills field and LinkedIn's description field actually recurs across the sample. The output is a short report, not a spreadsheet dump — a range, a skills list, and the sample size behind each.

What can't the agent do for you?

Two cases.

Not every posting discloses salary. A meaningful share of LinkedIn and Indeed postings leave salaryMin/salaryMax empty — pay transparency laws vary by state and country, and plenty of employers just don't list a number. The agent's range only reflects the postings that did disclose one, so a small disclosed sample against a much larger total posting count is worth flagging in the output, not treating as the full picture.

Currency and unit conversion aren't automatic. LinkedIn and Indeed return salaryCurrency per row (typically USD for US searches), while Naukri's benchmark fields are always in Lakhs per annum. The agent reads both correctly, but merging them into a single cross-market number is a judgment call you make, not something either endpoint does for you.

Which endpoint should you use for which job?

FAQ