Job Postings API: Turning Hiring Into a Buying Signal
A job ad says what a company is building before its website does. Which endpoint returns postings, what the record contains, and the fields nobody reads.
A company's job ads describe what it is building roughly a quarter before its website does. Marketing pages are written after a decision; a job ad is written to execute one, which is why hiring is the cleanest early signal available in public data.
Most people reach for jobs data as a job seeker or a recruiter. This is about the third use: reading postings as evidence about a company. Monid is the OpenRouter for agent tools, and the endpoints below sit on one key.
Fair disclosure: you are on the Monid blog. The section near the end says where a dedicated jobs platform beats this, and it is a real list.
What can you actually learn from a job posting?
More than the title, and the fields that carry the signal are not the ones people read.
We ran a search on 2026-08-17 and read one record end to end: 32 fields, only two empty. The obvious ones are there, title, location, description, company, posted date. These are the ones worth knowing about:
applicants returned 25. A count of how many people applied, on a posting made the same day. That is a competitive-pressure reading you cannot get any other way, and for a recruiter or a candidate it is the single most decision-relevant number in the record.
hiringTeam returned a named person with a LinkedIn URL and a job title. Not the company, a human, on the posting. For outbound that is the difference between a company-level signal and a contactable one.
applicantTrackingSystem returned the ATS the posting runs on. That is technographic data arriving inside a jobs record, for free, and it tells you what recruiting stack a company has bought.
expireAt returned a date a month out. Postings have a shelf life, and knowing when one closes is what separates a live signal from a stale one.
Two more that matter for filtering: workplaceType (remote, hybrid, onsite) and experienceLevel, both normalised rather than free text, so they filter cleanly.
salary came back empty. Its structure is there, with text, min and max, and all three were null. Salary is only populated where a jurisdiction requires disclosure or an employer volunteers it, so any analysis built on compensation will have large holes that are not random: they cluster by geography.
Which API returns job postings?
Two shapes, and they answer different questions.
Search across the market. apify /harvestapi/linkedin-job-search takes job titles and locations with filters, and returns postings. This is the one for signal work, because you are asking "who is hiring for this" rather than "what is this company hiring for".
monid inspect -p apify -e /harvestapi/linkedin-job-search
monid run -p apify -e /harvestapi/linkedin-job-search \
-i '{"jobTitles":["data engineer"],"locations":["Berlin"],"maxItems":25}'
Read the billing note on that endpoint before scaling it: it runs once per query in jobTitles, so results are roughly queries multiplied by the per-query limit. Two extra titles is not a small change to the bill. Pass one query first and look at what comes back.
A known company's openings. apollo /organizations/{id}/job_postings returns the active postings for a company you have already identified. This is the one for account research: you have the account, you want to know what it is staffing up.
There is also strale /x402/job-posting-analyze, which takes a single posting and extracts structured attributes from the prose. Useful when the description text carries what you need and the structured fields do not.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-key> -l main
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to show me what I can do for Jobs.📖 See also which LinkedIn job API stays fresh, which tests the freshness question directly.
How do you turn postings into a buying signal?
By reading the pattern across postings, not the content of any one.
A single job ad tells you a company needs a person. A pattern tells you what it decided. Four readings that hold up:
Volume by function is a budget signal. A company posting six sales roles has closed a funding round or hit a number. Sales headcount is the most reliably lagging indicator of revenue confidence there is.
A first hire in a function is the strongest signal of all. The first data engineer, the first security hire, the first solutions architect. It means the function is being started rather than staffed, which is exactly when tooling gets bought, because nothing has been chosen yet.
Titles in the description are a technographic read. A posting naming Snowflake and dbt has told you the stack more reliably than any detection tool, because someone had to be sure enough to hire against it.
The ATS field tells you how they buy. A company on an enterprise ATS runs a procurement process. One on a lightweight tool does not. That changes who you talk to and how long it takes.
The one that misleads: a role reposted is not a new signal. Postings expire and get refreshed, so a naive daily pull counts the same opening repeatedly and reads as accelerating hiring. Deduplicate on the posting id and treat postedDate as the truth, not the day you saw it.
The pipeline that works
Resolve, filter, then enrich, in that order.
monid run -p akta -e /v1/company/search --query '{"query":"<company name>"}'
Resolution is free, so start there and get domains. Filter your list on what the postings say. Only then pay for enrichment on what survives, because enrichment is priced per record and filtering is not.
What the record cannot tell you
Three limits worth knowing before a dashboard is built on this.
A posting is not a hire. Roles get cancelled, filled internally, or left open as a pipeline-building exercise. Counting postings as headcount growth overstates it, and the overstatement is largest at companies that always have openings.
Volume is confounded by turnover. Six sales postings can mean growth or churn, and the record cannot distinguish them. The tell is repetition over time: the same title reappearing every quarter is a retention problem wearing a growth signal's clothes.
Location is where the role sits, not where the company is. A remote posting in one market says nothing about headquarters, and the workplaceType field matters more than location for any territory analysis.
The general shape: postings are strong evidence about intent and weak evidence about outcome. For what a company decided to build, they are close to the best public source. For how big it is or how fast it is growing, use headcount and firmographics, which is what turning a domain into full firmographics covers, and pair it with company data pulled on a schedule if the trend matters more than the snapshot.
If the postings are feeding a prospect list rather than a report, wiring up an ICP search is the step that follows.
Which endpoint should I use for which job?
| Job | Endpoint | Takes | Billing shape |
|---|---|---|---|
| Who is hiring for this role | apify /harvestapi/linkedin-job-search | Titles, locations, filters | Per result plus flat fee |
| What is this company hiring for | apollo /organizations/{id}/job_postings | Organization id | Per call |
| Structure one posting's prose | strale /x402/job-posting-analyze | A posting | Per call |
| Resolve a company name first | akta /v1/company/search | Name or website | Free per call |
| Enrich the companies that pass | pdl /v5/company/enrich | Website | Per call |
Verified present on 2026-08-17 with monid discover. The billing column gives the shape rather than a figure; monid inspect prints the current figure and costs nothing.
The multiplication on the first row is the one to watch. It bills per result, and results scale with your title list times your limit, so the cheapest mistake in this category is an ambitious jobTitles array on the first run.
Reading a description properly
The structured fields filter; the description text is where the signal lives, and most pipelines throw it away.
Three things worth extracting from the prose, none of which appear in a structured field:
Named technologies. A description listing the stack is the strongest technographic evidence available publicly, because someone had to be certain enough to hire against it. We compared that against page-based detection in the technographic comparison, where a scan of a major site returned only infrastructure.
Team shape. "Reporting to the Head of Data" and "you will be our first data hire" describe two different companies with the same job title, and only the prose distinguishes them.
Urgency language. "Immediate start", "backfill", "newly created role". Each implies a different buying situation, and the first two often mean the budget already exists.
The structured route for this is strale /x402/job-posting-analyze, which extracts attributes from a posting's text. The cheaper route, if you are already holding the description, is to read it: the field is in the record and costs nothing extra.
When should you not use Monid?
You are building a job board. That is a licensing conversation with the sources, not a scraping one, and the terms matter more than the endpoint does.
You need complete market coverage. A search returns what the platform surfaces for your query, which is not every opening that exists. For headcount analytics that must be exhaustive, buy a dataset built for it.
You need salary data. As measured above, the field exists and is mostly empty, and its emptiness correlates with geography. Compensation benchmarking needs a source that specialises in it.
You need historical postings. These endpoints read what is live. A closed role is gone, so trend analysis means collecting daily from now rather than querying backwards.
And the caution about us. Metadata in this catalogue has disagreed with real behaviour before, including an endpoint that returned empty commercial fields at full price. Run one small call, read the fields and the charge, then scale.
Conclusion
A job posting is a company telling you what it decided, in public, before it announces anything. The reason it is under-used as a signal is that people read the title and stop, when the useful fields are the applicant count, the named hiring contact, the ATS and the expiry date.
Two things matter more than which endpoint you pick. Read patterns, not postings: the first hire in a function beats ten more of the same role, because it means the function is being started rather than staffed. And deduplicate on posting id, because refreshed listings otherwise read as accelerating hiring and every dashboard built on a daily pull gets this wrong at least once.
Start with the free part: monid discover -q "job postings" lists what exists, monid inspect shows the schema and price without spending, and company resolution costs nothing. Then run one title before you run twenty. Begin at monid.ai.
FAQ
Why is the salary field usually empty?
Because disclosure is a legal requirement in some jurisdictions and voluntary everywhere else. The field is structured with text, minimum and maximum, and on the record we measured all three were null. The important part is that the gaps are not random: they cluster by geography, so any comparison across regions is comparing places that must disclose against places that need not.
Can I see how many people applied?
Yes, on the platform that reports it. The record we measured carried an applicant count on a posting made the same day. Treat it as a snapshot rather than a series, because it only rises and there is no history in the record: if you want the curve, you have to collect it yourself on a schedule.
How do I avoid counting the same job twice?
Deduplicate on the posting id and trust the posted date over the date you collected it. Postings expire and employers refresh them, so a role that has been open for months can appear repeatedly in a daily pull and read as new demand. This is the most common error in hiring dashboards and it always inflates in the same direction.
Is scraping job postings allowed?
Public postings sit in the same contested area as other public-page scraping, and each platform's terms restrict automated access differently. Get your own legal read before running at scale, prefer verified providers, and note that building a competing job board is a different question from reading postings as a business signal, with different exposure.
Last updated August 2026.
