Jooble API and Job Postings Data: Hiring as a Buying Signal

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.

Is there a Jooble API?

There is, and it is not the kind of API the question usually means.

What Jooble offers

Jooble is a job aggregator, and its API is offered to partners that integrate its listings, through an application, rather than as a self-serve developer key you sign up for and start calling. If you run a job board or a career site and want Jooble's inventory inside it, that is the door. If you are a developer who wants job postings as data inside a pipeline, it is not.

What you get instead

Per-call job search endpoints that read the major platforms directly. We re-ran the main one on 2026-09-15, ten postings for one title in one city, and read every field again. Thirty-two fields per row, as on 2026-08-17. Two of them turned out to mean something different from what they look like.

applicants is a bucket, not a count. Across ten postings the field took five distinct values: 25, 25, 25, 200, 41, 200, 25, 25, 200, 34. Five postings said exactly 25 and three said exactly 200. Those are the platform's display thresholds, "25 applicants" and "over 200 applicants", passed through as if they were numbers. Two rows carried what look like real counts, 41 and 34. A model that treats this column as continuous is averaging labels.

expireAt is a default, not a decision. Seven of ten rows carried the same expiry, 2026-10-15, exactly thirty days from the day we pulled. The other three were six months or a year out. The thirty-day value is what the platform assigns when the employer sets nothing, so on most rows it tells you when the posting was made, not when the role closes.

salary was null on all ten, unchanged from the first measurement. applicantTrackingSystem was populated on four of ten, LinkedIn on three and Workday on one. hiringTeam carried a named person on four of ten.

A second source, for shape

builtin/search_jobs for the same title and city returned twenty-five postings with eleven flat fields each: id, title, url, company, work type, location, salary, experience level and posted date, paged. Fewer fields, no applicant count, no ATS, and a salary field that is at least present as a column. Two sources, two shapes, and neither is the aggregator's partner feed.

The honest answer to the query

If "jooble api" means "I want to embed Jooble's listings", apply to Jooble. If it means "I want job postings as data", the rest of this article is the answer, and the two fields above are the first thing to fix in any pipeline built on it.

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

📖 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?

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

Last updated September 2026.