How the API works

The Jobs API collects job postings at the source: employers' applicant tracking systems (Workday, iCIMS, Greenhouse, SmartRecruiters, UKG and dozens more), their own career sites, and public-sector job portals. Every job links to the posting it was collected from.

Coverage

  • Canada and the United States. Each job belongs to a country view (CA or US), admitted only when a location in that country is verified. A bare "London" or "CA" is never taken as Canada or California.
  • Hourly collection. Active employer boards are checked about every hour; boards with no current jobs less often.
  • Verified closures. A job expires only after it is missing from two complete scans at least two hours apart. Failed or partial scans never remove jobs.
  • The full posting. Descriptions in text and original HTML, every location, published pay, employment types and, for many sources, extra structured facts such as department and qualifications with their source path.

Two ways to read it

APIUseWhat it does
FeedsKeep a copyPoll /v1/active-ats every hour (or day) for new jobs, /v1/expired-ats for removals and /v1/modified-ats for changes. Plain JSON arrays, offset or cursor pagination, Google-style search and full-name location filters.
SearchQuery liveSearch one country with /v1/jobs, fetch one job, or follow /v1/changes, an ordered log of every created, updated, expired and excluded job, seconds behind collection.

Both read the same catalogue and use the same job ids, so you can backfill with one and stay current with the other.

What we don't do

  • No invented data. Fields the employer didn't publish stay null. We don't estimate salaries, seniority or skills, and we don't attach third-party company profiles. If you add your own enrichment, keep it separate from employer-stated facts.
  • No LinkedIn or Indeed. We don't scrape them; a job that appears there is collected from the employer's own source instead.

See Job fields for exactly what each field contains.

Built for ingestion

The feeds are designed for loading into your own database on a schedule, then serving your users from there. Calling the API on every page view of your site works, but costs a request each time and adds network latency to your pages. The recommended strategy walks through a complete sync.