SEEK API: what it does, what it cannot do, and how to get Australian jobs data

Search for the SEEK API and you are probably one of three people. A developer building a job board, a sourcing tool or an agent that needs Australian and New Zealand postings. An ATS or HR-tech vendor whose customers want their openings pushed onto SEEK and the applications pulled back. Or an analyst who wants APAC hiring data in rows and columns rather than a search box. SEEK is the dominant employment marketplace in Australia and New Zealand, and through JobStreet and JobsDB it now runs much of South-East Asia too, so all three questions are reasonable. Only one of them has an official answer.

The short answer

Unlike most large job boards, SEEK has a real, public, genuinely good developer platform. The SEEK API is GraphQL, modelled on HR Open Standards, with a schema browser and a playground, and it covers four use cases: Job Posting (advertise on SEEK with custom questions, granular locations and variable pricing), Optimised Apply (export candidate applications into recruitment software), Apply with SEEK (let candidates pre-fill your forms from their SEEK Profile) and the Ad Performance Panel.

And then, in SEEK’s own documentation, the sentence that ends most developers’ search: “The SEEK API does not offer programmatic job search capabilities.” That is not a footnote or a roadmap item. It is the design.

The API is built for hirers, not for readers

You can see the shape of it in the auth model. Access runs on OAuth 2.0 client credentials issued to your organisation, exchanged for two kinds of token: partner tokens, which authenticate your backend and grant access to the data of any SEEK hirer you already have a relationship with, and browser tokens, restricted to a single hirer and a specific set of actions on that hirer’s behalf. You get credentials by filling out an Integration Request form, and SEEK’s support team explicitly configures each hirer relationship during onboarding. There is no self-serve key, because every call is anchored to a hirer who agreed to be represented by you.

The closest thing to reading job ads is a use case SEEK calls reflecting job ads. The positionProfile query takes a positionProfileId and returns a PostedPositionProfile with posting instructions, branding images, a positionUri to the SEEK listing and a seekApplicationUri to the apply form. It exists so a vendor can mirror its own customer’s live ads onto that customer’s internal careers portal. Note what it requires: an id you only possess because you posted the ad. There is no list query, no filter, no keyword. SEEK is even explicit that the retrieval side stops there - your software, the docs say, will need to ingest the ads into a search index to serve the portal.

The reasoning is the same one that drove Indeed to retire its public API keys and keeps LinkedIn jobs behind partner agreements. A marketplace sells outcomes to employers and attention to candidates; the listings database is the moat. Opening a read API on it hands the moat to anyone with a cron job.

What “SEEK API integration” means when a vendor advertises it

Almost always Job Posting plus Optimised Apply: their ATS pushes a customer’s vacancy onto SEEK, SEEK returns the ad state and the applications, and the recruiter never leaves the ATS. If that is what you are building, you are in a better position than the equivalent developer in India staring at a board with no developer portal at all - the SEEK docs are public, the schema is inspectable before you commit, and the request form is a real front door. Budget for partner onboarding, not an afternoon: credentials, relationship configuration per hirer, and a review of your integration are all part of it.

The unofficial route, and what it actually costs

Because the demand for the read side is real and unmet, an ecosystem has grown in the gap: reverse-engineered projects that call the internal JSON endpoints seek.com.au’s own front end uses, and scraping vendors who sell SEEK scrapers per page. Be clear-eyed about both. Internal endpoints carry no compatibility promise and change without notice. Automated access to the site sits against SEEK’s terms, which is a question for your counsel rather than a blog post. And you inherit the standard scraper-output problems: the same vacancy duplicated across ads, expired listings that still render fine, and no signal at all for the moment a role actually closed. None of that is fatal for a weekend experiment. All of it compounds into maintenance once a product depends on it.

The aggregator path, and the disclosure that comes first

A few jobs-data vendors resell board-sourced postings at data-contract prices. So, the honest disclosure before the numbers: JobsPipe does not index SEEK. Our coverage of the region comes from sources that publish openly and are collected directly - LinkedIn, Indeed, public Workday tenants, Workable, SmartRecruiters, Lever and Y Combinator - deduplicated into one record per vacancy and liveness-checked, so closed roles leave the corpus instead of haunting it.

Measured against the live database on the day this post published: 42,589 active postings located in Australia, 17,330 of them posted in the last 30 days. By source, LinkedIn contributes 27,877, Indeed 10,745, Workday 3,159, Workable 506 and SmartRecruiters 270. By city, Sydney leads with 6,740, then Melbourne (4,132), Brisbane (2,297), Perth (1,719), Adelaide (798) and Canberra (690). New Zealand adds 2,281 live postings, Auckland first. And because SEEK’s brands now span the region, the comparison worth having is APAC-wide: Singapore sits at 22,184 active postings, the Philippines at 11,266, Malaysia at 1,914.

Two things follow from how that corpus is collected, and both are worth saying out loud. It skews toward multinationals, tech companies and employers hiring through global ATSs and LinkedIn, so SEEK’s long tail of local and SME advertising is broader than what we see. And every record in it is verified open and classified: 40,303 of the 42,589 Australian postings carry extracted skills, each classified posting gets an ISCO-08 occupation code and an industry code (733 live Australian roles sit under 2512, software developers), and 6,744 state a salary because the employer published one. That is the difference between a mirror of one board and a dataset you can query.

Querying the region in one request

Country, city, skills and freshness are filters here, not scraping projects:

curl -X POST "https://api.jobspipe.dev/v1/jobs/search" \
  -H "Authorization: Bearer jp_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "job_country_code_or": ["AU", "NZ"],
    "job_location_or": ["Sydney", "Melbourne"],
    "skills_or": ["python", "aws"],
    "posted_at_max_age_days": 30,
    "limit": 25
  }'

Swap job_location_or for any city or region string, add job_title_or for title matching, or "occupation_code_or": ["2512"] to sweep every software-developer role regardless of how the title is phrased. Each record comes back with job_title, company, the url and final_url pointing at the original listing, date_posted, seniority, min_annual_salary / max_annual_salary with salary_currency where the employer stated one, technology_slugs, occupation_code with its occupation_label, and a status plus closed_at so you know when a vacancy died. The free tier is 100 requests a month, no card and no partner review.

So which path is yours

• Posting ads to SEEK from your product. Use the SEEK API. It is the only real option, it is well documented, and it does the job it was built for. Start at the Integration Request form.
• Reflecting your own customers’ ads. Also the SEEK API, via positionProfile - but plan to run your own search index over what you ingest.
• Reading the market. There is no official route, and there will not be one. Either accept the cost and fragility of scraping a board that does not want to be scraped, or read the layer underneath it, where employers publish the same vacancies openly. The jobs API comparison covers every option in that second category.