HiBob Jobs API
How HiBob's careers boards actually work, why a bare request gets a 401 and a Referer header gets a 200, and what ?source=hibob does and doesn't carry.
HiBob (the product is usually just called Bob) is an HR platform for mid-market
companies, strongest in tech, and its careers module ships public boards at
<tenant>.careers.hibob.com. One unauthenticated call returns a tenant's whole
board with every description inline. No pagination, no detail pass.
The word "unauthenticated" is doing something specific there, and it's the interesting part of this platform.
401 bare, 200 with a Referer#
# 401 {"servlet":"jersey","message":"Unauthorized"}
curl "https://<tenant>.careers.hibob.com/api/job-ad"
# 200, whole board, bodies inline
curl "https://<tenant>.careers.hibob.com/api/job-ad" \
-H "Referer: https://<tenant>.careers.hibob.com/jobs"That is the entire unlock. Add the header the board's own front-end sends, and the same endpoint that just refused you returns everything.
It is specifically Referer
Origin does not substitute. Sending Origin alone still gets the 401. Only
Referer opens it.
It is worth being precise about what this is, because the 401 reads like an auth wall and isn't one. There is no token to mint, no key to register, no session to hold. It is a referrer check on an endpoint that is otherwise entirely public — the kind of thing that stops a browser on the wrong page and stops nothing else.
HiBob does also publish a documented Hiring API that genuinely requires a bearer token. That is a different product for its own customers, and it is not what a public board reads from. The endpoint above is the careers SPA's own.
What bites you#
The body is four separate fields, and each one alone is about half a posting.
There is no single description. HiBob splits it into description,
responsibilities, requirements and benefits, with tenant-customized headings
in a sectionLabels object. Read only description and you get the opening
pitch with none of the actual requirements — which looks like a populated field,
so nothing alerts you. All four have to be joined back together, ideally under
the labels the tenant chose.
There is no posting date. The endpoint exposes no publish timestamp of any kind, so a date on a HiBob posting was inferred by whoever indexed it rather than published by HiBob.
Ids are tenant-local. They collide across boards, so anything using them as a dedup key has to scope them by tenant first.
Salary exists only where pay transparency law puts it. Some rows carry a real structured range with a currency and a period. Most don't. That's the employer's jurisdiction showing through, not a parsing gap.
Where this stands#
Query it with ?source=hibob. Bodies arrive whole — 79 of 79 on the reference
board — but only because all four blocks are joined on the way in.
The honest gap is company identity, and HiBob is the clearest case of it in the
pool. A scraped job that can't reach a company is worth very little, and HiBob
measured 0% in the last identity audit: the board page publishes no
structured employer domain, no canonical URL pointing at the company's own site,
and nothing else that resolves. It is also a good example of why that number has
to be measured rather than assumed — an early pass "found" a domain for HiBob
boards and it was typography.com, the font vendor. A wrong company is worse
than no company, because it's unfalsifiable downstream.
That gap is a property of the boards rather than of the board list, so it doesn't
close by adding tenants. The counts and the fill rates do move, though: read them
off /v1/meta → sources, which is the only
vocabulary worth coding against.
See all platforms · coverage · the company object
Every source above normalises onto the same schema, with the hiring company already joined onto each posting.
Get an API key