A job posting is a company telling you, in public and in detail, what it has decided to spend money on.
That is a strange thing to ignore, and most go-to-market teams ignore it. They will pay for intent data assembled from anonymous browsing behavior, then walk past a document where a company states its priorities explicitly, names the tools it uses, and reveals which team is growing.
Hiring signals are underused because reading them well takes more thought than reading a funding announcement. This post covers what job postings actually reveal, the inference mistakes that make people distrust the signal, and how to pull the data programmatically.
What a posting tells you that nothing else does
Start with what is genuinely encoded in a job listing, because it is more than most people extract.
Budget was approved. This is the strongest and most overlooked part. A posting is not an aspiration. Somebody made a headcount request, finance approved it, and the role went live. That is a completed internal budget cycle, made visible. Compare that to intent data, which tells you somebody at a company read an article.
Priorities are stated. The responsibilities section is a roadmap in disguise. A company hiring its first data engineer is about to build a data platform. A company hiring three compliance people is preparing for something specific. The posting describes work that does not exist yet, which means it describes the near future rather than the present.
The tech stack is listed. Requirements sections name tools. This is the cleanest technographic signal available, because it is self-reported by the people who use the tools, not inferred from a script tag on a marketing site. If you sell something adjacent to what they list, you have both a qualification and an opener.
Team shape is visible. Who the role reports to, whether it is a new function or a backfill, and what seniority band it sits in all tell you how the organization is structured and where authority sits.
Timing is unambiguous. A posting has a date. Unlike most firmographic data, you know exactly how fresh the signal is.
The signals worth acting on
Not all hiring activity means anything. Here are the patterns that carry information, and what each one implies.
A first hire in a function. The highest-value signal on this list. A company posting its first security engineer, first RevOps role, or first data engineer is standing up a capability from nothing. Nobody owns the budget yet, no vendor is entrenched, and the person being hired will be asked to choose tools in their first quarter. If you sell into that function, this is the moment.
Sudden concentration. Five engineering roles posted in three weeks by a company that normally posts one a quarter is a decision that already happened. Something got funded. The absolute number matters less than the change against that company's own baseline.
Seniority inversion. A director-level hire posted before the individual contributors is a team being built top-down, which usually means a strategic bet rather than capacity backfill. The reverse, ICs before leadership, is usually just growth.
Backfill velocity. The same role posted repeatedly at the same company is a retention problem in that team. Read it carefully: it is a genuine pain signal if you sell something that addresses the underlying cause, and it is a warning if you are selling to a seat that keeps turning over.
Stack migration language. Postings asking for experience in two competing technologies, or mentioning a migration explicitly, tell you a transition is underway. Transitions are when tooling decisions get reopened.
Geographic expansion. A first posting in a new country means market entry, which brings a wave of local vendor selection with it.
The inference mistakes that ruin the signal
This is where most hiring-signal programs fail, and why some teams conclude the data does not work.
A posting is not a purchase intent. A company hiring a data engineer might be about to buy a data platform, or might be about to build one instead of buying. The posting tells you the priority exists, not which way they will resolve it. Treat it as a reason to have a conversation, never as a qualified need.
Stale postings look identical to live ones. Postings linger after roles are filled, and some companies never take them down. Always filter on recency, and treat anything older than about sixty days as unreliable unless you can confirm it is still active.
Aggregate counts mislead badly. "This company has 40 open roles" means almost nothing without knowing whether that is high or low for them. A 4,000-person company with 40 openings is at rest. A 60-person company with 40 openings just raised a round. Always normalize against headcount and against that company's own history.
Job descriptions are partly boilerplate. Requirements lists are frequently copied between postings and inflated by templates. A tool mentioned once in a long list of nice-to-haves is weak evidence. The same tool named in the responsibilities section, in multiple postings, is real.
Recruiting agencies pollute the data. Some postings are agencies fishing rather than companies hiring. Check whether the posting sits on the company itself before acting.
Pulling the data
Job postings live in the Live API, because postings change constantly and a stale snapshot of a job market is worth very little.
The broad discovery endpoint searches postings by keyword with a substantial filter set:
1from renidly import Renidly
2
3renidly = Renidly() # reads RENIDLY_API_KEY from the environment
4
5results = renidly.live.discover.opportunities(
6 keyword="revenue operations",
7 datePosted="1week",
8 experience="director",
9 workplaceTypes="remote",
10 sortBy="date_posted",
11 count=25,
12)If your stack is Node, the same call, and note the filter keys keep their camelCase form in both languages because they are Live API parameters:
1import { Renidly } from "renidly";
2
3const renidly = new Renidly();
4
5const results = await renidly.live.discover.opportunities({
6 keyword: "revenue operations",
7 datePosted: "1week",
8 experience: "director",
9 workplaceTypes: "remote",
10 sortBy: "date_posted",
11 count: 25,
12});datePosted accepts 24h, 1week or 1month, and using it is not optional in production. It is the difference between a live signal and a list of roles that were filled in March.
Other filters worth knowing: experience spans internship through executive, jobTypes covers employment arrangement, workplaceTypes handles onsite, remote and hybrid, and companies, industries, locations, functions and titles narrow further. There are also flags like under10Applicants, which is a genuinely interesting one, since a role with few applicants is a role the company is struggling to fill and therefore feeling pressure on.
Watching accounts rather than searching broadly
Broad discovery is for market research. For go-to-market, you usually want the opposite: a fixed set of accounts, watched continuously.
1postings = renidly.live.organizations.opportunities(
2 organization_entity_ids="org_5ehe8408s7tme,org_06d0d44dogo2m",
3 start=0,
4)
5
6print(postings.total, postings.hasMore)1const postings = await renidly.live.organizations.opportunities({
2 organizationEntityIds: "org_5ehe8408s7tme,org_06d0d44dogo2m",
3 start: 0,
4});Page size is fixed at 50 and you advance with start as an offset. Run this daily against your target list, diff against yesterday, and act on what is new. The diff is the signal, not the total.
That diffing step is the part people skip, and it fails the same way job-change monitoring does: the endpoint returns a current state, not a changelog, so if you act on everything it returns you will contact the same account every day. Keep a seen-set keyed on the posting identifier with a TTL longer than your polling window. The full pattern, including the deduplication problem in detail, is in job change signals.
The endpoint most people miss
Here is the one that turns a signal into a conversation.
1team = renidly.live.opportunities.hiring_team(opportunity_entity_id="...")1const team = await renidly.live.opportunities.hiringTeam({ opportunityEntityId: "..." });A posting tells you a company is investing in something. The hiring team tells you who owns that investment. That is usually the hiring manager, which is usually the person with the budget, which is the person you actually wanted to reach.
Most teams stop at "this company is hiring" and hand a rep an account name. Going one step further gives them a named individual with a documented, current, public priority. Those are completely different quality of lead.
There are two more endpoints in the same family worth knowing. live.opportunities.similar() finds comparable postings, which is useful for building a market view of who else is hiring the same role. And live.opportunities.by_person() returns postings created by a specific person, which surfaces everything a given hiring manager or founder currently has open.
Turning postings into an account score
Raw postings are not a queue. Score them, cut to what your team can actually work, and dispatch the rest to nobody.
A weighted model that works reasonably well:
1def hiring_score(account, postings) -> int:
2 s = 0
3
4 # Volume relative to this company's own baseline, not absolute
5 ratio = len(postings) / max(account.baseline_postings, 1)
6 if ratio >= 3: s += 30
7 elif ratio >= 2: s += 15
8
9 # First hire in a function you sell into
10 if any(is_first_in_function(account, p) for p in postings):
11 s += 40
12
13 # Your stack appears in requirements
14 if any(mentions_adjacent_tech(p) for p in postings):
15 s += 25
16
17 # Seniority: someone who can sign
18 if any(p.experience in ("director", "executive") for p in postings):
19 s += 20
20
21 # Recency decay
22 newest = min(p.days_since_posted for p in postings)
23 if newest > 30: s = int(s * 0.5)
24
25 return sTwo design notes. Normalizing against the account's own baseline is what stops large companies dominating your queue purely by being large. And the first-in-function bonus is weighted highest deliberately, because it is the only signal on the list that identifies a moment where no incumbent vendor exists.
Hiring activity pairs naturally with movement data, since a team that is both losing people and posting to replace them is a different situation from one that is expanding. The free job change detector is a quick way to check the movement side of an account before you build a watch for it.
Once an account scores well, resolve the hiring team into contactable people. That is a different problem with a different set of endpoints, and the mechanics of turning a person into a verified address are in reverse email lookup and the email verification guide.
Beyond sales: three other uses
Hiring data is not only a prospecting signal, and the other applications are often easier to justify internally.
Market research. Hiring across a sector is a leading indicator of where investment is flowing, usually months ahead of anything that shows up in reported financials. Tracking postings by function across an industry tells you which capabilities are being built out right now. That is the shape of the market research use case, and the filtering techniques that keep a market query from returning everything are in ICP filtering.
Competitive intelligence. A competitor's postings reveal their roadmap with unusual clarity. Roles reveal products, requirements reveal stack, locations reveal expansion, and seniority reveals whether a bet is strategic or incremental.
Recruiting and talent. For anyone building recruiting products, postings plus hiring teams plus candidate data is the core loop. See recruiting and HR.
Cost and cadence
Postings are Live API calls, and Live API calls cost more than dataset reads because they return the freshest available state rather than a stored snapshot. That is the correct tradeoff here, since stale job data is close to worthless, but it means cadence discipline matters.
Three habits:
Poll daily, not hourly. Hiring moves in days. Polling faster costs more and surfaces nothing new.
Watch a bounded account list. Broad discovery is for periodic market analysis, not for a daily job. Watching 500 named accounts is cheap and actionable. Discovering across an entire industry every morning is neither.
Cache aggressively. A posting's details do not change after it goes live. Fetch full details once per posting identifier and keep them. Only the set of open postings needs re-checking.
Every response reports the credits it consumed, so cost per scored account is something you compute from your own logs rather than reconstruct from an invoice. Current per-route costs are on the pricing page, and if you are running this alongside other enrichment work, the budgeting approach in batch enrichment at scale applies.
The argument against hiring signals
Now the honest part, because this signal is oversold.
It is not universal. If you sell to companies that rarely hire, or into functions that are not typically posted publicly, there is not enough signal to build on. Test whether your existing customer base was visibly hiring before they bought, using accounts you closed last year. If the pattern is not there historically, it will not be there prospectively.
Timing is coarse. A posting tells you a priority exists. It does not tell you where in a buying cycle the company is. You may be three weeks early or six months late, and the posting looks the same either way.
It is public, so it is not proprietary. Everyone can see the same postings. If your entire differentiation is noticing that a company is hiring, your competitors noticed too. The edge comes from the inference layer: connecting a posting to the right person, at the right seniority, with a message about the problem they were hired to solve.
Volume is deceptive. Broad discovery returns a lot of results, and a large queue feels like progress. A rep who receives four hundred scored accounts works none of them. Cut hard.
The realistic framing is that hiring signals are a prioritization input, not a lead source. They tell you which of the accounts you already care about deserve attention this month. Used that way they are excellent. Used as a way to generate net-new lists they mostly produce noise.
The one-line version
Read postings as evidence that budget was approved and a priority was stated, not as purchase intent. Normalize volume against each company's own baseline instead of absolute counts. Weight first-hires-in-a-function highest, because that is the only moment with no incumbent. Always filter on recency. And go one step past the posting to the hiring team, because a named budget owner with a public, current priority is a completely different lead from an account name.
The fastest way to know whether this is worth building for your business is retrospective. Take twenty accounts you closed in the last year and check what they were hiring for in the ninety days before the deal started. If you want to sanity-check a few of the people involved first, the free tools will resolve a single person or address without any setup. If a pattern is there, it will be obvious immediately, and it will tell you exactly which functions to watch.
There are 100 free credits with no card required, which covers that retrospective comfortably. The Quickstart takes about five minutes.
