Open Jobs
Summarise what a company is hiring for from public job postings — total openings, function areas, technologies, and locations — from a domain.
What it answers
The Open Jobs signal summarises a company's current hiring from public job postings, framed for market and competitive intelligence: what a company is building and investing in, rather than who to contact. It reports how many roles are open, the function areas and technologies behind them, and where the roles are.
Key: open-jobs · Scope: company · Cost: 2 credits
Counts vs examples
The distinction that matters when reading this signal:
openingsis the true total of roles matching the trailing 90-day window. It comes from the job search's reported match count, not from the handful of listings the signal samples, so it is reliable even though the other fields are drawn from a small sample.topTitles,hiringThemes,techHiringFor, andlocationsare examples taken from that sample. They illustrate what and where the company is hiring — they are not a ranked or proportional breakdown, and you should not read percentages into them.
hiringThemes maps sampled roles onto a fixed function taxonomy (Engineering, Data/ML, Product, Sales/GTM, Marketing, Operations, Finance/Legal, People/HR, Support, Other), so the field stays filterable and stable across runs instead of drifting between synonyms.
Request
Provide only a domain.
curl -X POST https://api.saber.app/v1/signals/sync/open-jobs \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"domain": "datadoghq.com"
}'For webhook delivery, call POST /v1/signals/open-jobs (async) with a webhookUrl instead.
| Field | Type | Required | Description |
|---|---|---|---|
domain | string | yes | Company domain to research. |
webhookUrl | string | no | Where to deliver the completed result. Intended for the async endpoint; if supplied on sync, the webhook still fires in addition to the response. |
forceRefresh | boolean | no | Bypass the cache and force a fresh run. |
Response
answer.jsonSchema conforms to the open-jobs answer schema:
{
"openings": 876,
"topTitles": ["Senior Software Engineer", "Product Manager", "Enterprise Account Executive"],
"hiringThemes": ["Engineering", "Product", "Sales/GTM"],
"techHiringFor": ["Go", "Kubernetes", "React"],
"locations": ["New York, NY", "Remote", "Paris, France"],
"latestPostingDate": "2026-06-28",
"source": "public_job_listings"
}| Field | Type | Description |
|---|---|---|
openings | integer | Total roles posted in the last 90 days — the true match count, not the sample size. 0 if none. |
topTitles | array | Representative verbatim job titles from the sample. Examples, not exhaustive. |
hiringThemes | array | Function areas from the fixed taxonomy. Examples of where the company is investing, not counted. |
techHiringFor | array | Technologies named in the sampled postings (forward-looking hiring intent). Taken from the postings, never inferred. |
locations | array | Representative locations (city/region/country or Remote). |
latestPostingDate | string | Most recent posting date in the sample, YYYY-MM-DD. |
source | string | Always public_job_listings. |
openings, topTitles, and source are always present; when openings is 0, the example arrays are empty.
Provenance. Every field is derived from public job postings (source is always public_job_listings); this signal reports aggregate counts and sampled examples rather than per-posting source URLs.
Relationship to the Tech signal
techHiringFor is the forward-looking complement to the Tech signal: Tech reports the stack a company runs today, while techHiringFor reports the technologies named in what they are hiring for now. Values are drawn from the postings' structured tags, not guessed from general knowledge.