The Perils of Guessing Job Board URLs

When building systems that ingest job data, a critical early step is mapping company names to their respective job board endpoints. Platforms like Greenhouse, Lever, and Ashby offer public, documented APIs. For Greenhouse, the structure is boards-api.greenhouse.io/v1/boards/<slug>/jobs. Lever uses api.lever.co/v0/postings/<slug>, and Ashby provides api.ashbyhq.com/posting-api/job-board/<slug>. These are all accessible without authentication, making them prime targets for automated discovery.

The logical first approach is to infer the <slug> from the company name. This typically involves lowercasing the company name, stripping punctuation, and attempting a connection. For instance, a company named "Airspace Link" might yield candidate slugs like airspacelink, airspace-link, or simply airspace.

However, this naive strategy is fraught with peril. My own measurements, conducted while building an index across 2,127 companies, reveal that this guessing method succeeds in finding *an* endpoint only about a quarter of the time. More alarmingly, of the endpoints that are found, a staggering 50% do not belong to the company whose name was used to guess the slug. This means that half of the data you discover through this method is misattributed, leading to flawed analysis and incorrect job listings in aggregators.

The verification step, therefore, becomes not just important, but essential. Without it, the discovery process is fundamentally unreliable. This issue is not trivial; it directly impacts the accuracy of job market analysis, recruitment technology, and any service relying on programmatic access to job postings.

Why Naive Slug Guessing Fails So Often

The core problem lies in the variability and non-standardization of slug generation across different companies and Applicant Tracking Systems (ATS). While the API endpoints themselves might follow a general pattern, the <slug> component is often a matter of internal company convention or the default setting within an ATS, rather than a strict, predictable mapping from the company name.

Consider the "Airspace Link" example again. If the company's actual ATS slug is airspacelink-jobs, a simple guess of airspace might lead to a valid endpoint, but it could belong to a completely different company that also happens to use "Airspace" as part of its name or has a similarly short slug. The ATSs themselves often allow for customization of these slugs, or companies may choose to use internal project names or abbreviations that bear little resemblance to their public-facing corporate identity.

Furthermore, many companies operate multiple brands or subsidiaries, each potentially with its own job board. A guess based on the parent company name might inadvertently hit a job board for a subsidiary, or vice versa. This ambiguity means that even when a guess returns a valid URL, the confidence that it belongs to the *intended* company is extremely low.

The sheer number of companies and the diverse ways they configure their ATS instances create a combinatorial explosion of possibilities. Without a robust verification mechanism, automated discovery tools are essentially casting a wide net and hoping for the best, with a high probability of catching the wrong fish.

The Cost of Misattribution

The consequences of misattributed job data ripple through the ecosystem. For job aggregators and marketplaces, this means:

  • Inaccurate Company Profiles: Job listings appear under the wrong corporate umbrella, distorting data on hiring trends, company growth, and industry-specific job markets.
  • Poor Candidate Experience: Job seekers might apply for roles at companies they have no interest in, or miss opportunities at the company they intended.
  • Wasted Resources: Companies that manage their own job boards may see irrelevant applications, while aggregators spend resources cleaning up erroneous data.
  • Flawed Analytics: Any analysis based on this data – from salary benchmarks to hiring velocity – will be fundamentally flawed.

For developers building tools in this space, the realization that discovery is unreliable forces a pivot towards more deterministic methods. This could involve leveraging partnerships, using official company-provided data feeds where available, or building more sophisticated disambiguation algorithms that go beyond simple string matching. The effort and cost associated with verifying discovered endpoints often outweigh the initial savings from automated guessing.

Moving Towards Reliable Job Data Discovery

The challenge highlights a broader issue in the programmatic access of business data: the tension between standardized APIs and decentralized, often idiosyncratic, configuration. While API structures for job boards are becoming more uniform, the human- और company-defined elements within them remain a significant source of entropy.

The solution requires a multi-pronged approach. Firstly, ATS providers could offer more explicit ways to discover and verify company-specific endpoints, perhaps through a central registry or a discoverable metadata endpoint associated with a company's public profile. Secondly, data aggregators must invest heavily in robust verification processes. This could involve cross-referencing discovered URLs with other known data points, such as company website domains, LinkedIn profiles, or even manual checks for a statistically significant sample.

Ultimately, while the allure of automated discovery through simple guessing is strong, the data shows it is an unreliable shortcut. Building accurate systems requires acknowledging the inherent messiness of real-world data and investing in the validation steps that ensure integrity. For anyone working with job data, understanding that half of your automatically discovered endpoints might be wrong is the crucial first step.