Job posting APIs: turn hiring activity into a buying-signal review queue
All Them APIs
Independent API research
A company hiring a developer advocate has given you a reason to research its developer program. It has not told you its budget, purchasing timeline or willingness to buy your product.
Job posting APIs are useful for finding that first observation at scale. The workflow works best when it returns "here is what changed, and here is the source," rather than "this account is ready to buy."
Choose between market discovery and an account watchlist
For market-wide discovery, a jobs-data provider can search across employers. For a fixed list of companies, an authorized public ATS feed may be enough. These are different coverage problems.
PredictLeads documents company job-opening lookups and a discovery endpoint. Its active_only filter includes freshness conditions beyond simply not being marked closed. Read those semantics before naming a column "currently hiring."
The Greenhouse Job Board API exposes published jobs for a board. It is not a search engine across every employer. Its public GET endpoints do not require authentication, while application submission is a separate authenticated operation.
Market discovery:
GET https://predictleads.com/api/v3/discover/job_openings
Known company:
GET https://predictleads.com/api/v3/companies/{domain}/job_openings
Known Greenhouse board:
GET https://boards-api.greenhouse.io/v1/boards/{board_token}/jobs
These are provider endpoint references. Use the respective provider's account, terms and request parameters; they are not aliases under our own API key.
Define a signal that could be wrong
"Hiring salespeople" is usually too broad. "First developer-relations role listed on the company's current careers page" is a narrower observation that a reviewer can check.
Pick a baseline and a comparison window. Preserve both first_seen_at and last_seen_at when the provider supplies them. First seen by a collector is not necessarily first published by the employer. An updated posting is not necessarily a new requisition.
If this is the first run of your monitor, call it a baseline. Do not label every existing role a new signal.
Deduplicate before counting
One requisition can appear on a company page, an ATS board and several job sites. A remote role can also appear under multiple locations. Counting URLs as jobs makes the company look busier than it is.
Prefer stable posting or requisition identifiers within a source. Across sources, use employer identity, title, location policy and links as evidence for a merge, and retain uncertain cases. Do not collapse two distinct jobs merely because they share a title.
Keep salary fields with currency, period and geography. A missing salary is unknown, not zero. A range for one location is not automatically the compensation for every location on the posting.
Connect the observation to the offer carefully
| Observation | Research question | Unsupported conclusion |
|---|---|---|
| Developer-relations role | Is the public documentation or community program changing? | They need our documentation product |
| Data engineering roles | What data infrastructure is publicly described? | They are replacing their warehouse |
| Several support openings | Has the customer base or support model changed? | Their support team is failing |
| A role mentions a technology | Is it a requirement, a migration or an optional skill? | That technology is deployed in production |
The research question is an invitation to inspect evidence. It should not become a personalized claim in an email without support.
A prompt for an agent-assisted monitor
Read the approved company watchlist and the previous posting snapshot.
Use the configured jobs provider or each company's permitted public ATS feed.
Collect role IDs, source URLs and observed/updated timestamps.
Deduplicate location variants and preserve uncertain merges for review.
Separate newly observed, changed, closed and unavailable records.
For relevant changes, suggest a research question with its source.
Do not claim purchase intent, contact candidates or send outreach.
Report provider failures separately from companies with no open roles.
Keep the schedule, page cap and request budget outside the prompt too. A failed page of results must not erase yesterday's jobs or make every role appear closed.
Evaluate the signal before enriching contacts
Review a sample of the queue against current source pages. Count duplicates, stale vacancies, wrong company matches and genuinely relevant observations. Only then decide whether contact enrichment is worth paying for.
Use the account-brief workflow for the next research step. If the actual goal is recruiting rather than sales, the candidate sourcing guide uses a different evidence and review boundary.