Skip to content

How we follow a job link to the real apply system

Technical version: ATS traversal strategy (WING-333)

When a job is not already on a known board API, WorkWingman may need to follow a public career page and find the real apply URL. This page explains the strategy in human terms; the technical doc has the exact ranking rules and ID patterns.

What “success” looks like

Find a single apply URL on a known hiring platform (Greenhouse, Lever, Ashby, iCIMS, Workday, and similar), extract a stable posting id when the URL shape allows it, and stop. If the page is ambiguous, protected, or a search index, return unknown rather than guessing.

The scanner looks at ordinary links (not mailto: / javascript:), then prefers:

  1. A known ATS URL that also says “Apply” (or similar) in its text or label
  2. A known ATS URL without apply wording
  3. A generic “Apply” handoff that looks like a real tracking hop (not a “how to apply” essay page)

It throws away subscribe/alerts/search/login-shaped noise. If two different ATS vendors appear with equal strength, it refuses to pick — unknown beats a wrong automation target.

When a full browser is needed

Plain HTTP is enough when the page returns real job text and normal links. A browser is only for true app shells, apply buttons that are not links, or heavily dynamic forms. Bot walls (403, Cloudflare challenges, and similar) are a hard stop — we do not “escalate” past them with stealth tricks as part of this strategy.

Guardrails

  • Cap redirects and page hops so loops die
  • Detect cycles by normalized URL
  • Treat secondary aggregator traps as dead ends
  • Prefer fail-closed unknown over a confident wrong tenant

Posting-id patterns for major vendors are listed in the technical twin; Phenom-style vanity careers are deliberately marked unknown without tenant-specific rules rather than guessed.