Job Search APIs: The 2026 Stack for Builders (Data and AI)

A job search API means two completely different things, and builders conflate them constantly. One is a job data API that supplies the postings. The other is an AI model API that supplies the intelligence to parse, match, and tailor them. A working job search product needs both, and the catch nobody mentions is that most of the big-name data APIs you would reach for first are dead or locked behind a partner program.

This guide separates the two layers, shows what actually works in 2026, and maps how they fit together.

Two things both called a “job search API”

When someone says “job search API,” they mean one of two layers, and knowing which one you are missing is the whole game.

The data layer. APIs that return job postings. You query by keyword, location, salary, or posted date, and you get listings back. This is where the jobs come from.

The intelligence layer. AI model APIs that do something with those postings and with a candidate. Parse a resume, match it against the listings, tailor a document, extract requirements. This is where the product gets smart.

You cannot build a job search tool with only one. Data with no intelligence is a job board from 2010. Intelligence with no data has nothing to reason over. Almost every “how do I build this” question is really a question about which of these two layers the person has not solved yet.

The data layer: the graveyard first

Before the options that work, the ones that do not, because this is where most tutorials will waste your week.

Indeed. The Indeed Publisher API, the one every old tutorial walks you through, was deprecated in 2023. The endpoints return 410 Gone. The APIs Indeed still ships are employer-side only, built for ATS partners to publish jobs into Indeed through a GraphQL sync API, not for reading postings out. There is no self-serve key for job search. Indeed also ended organic visibility for single-source feed jobs on March 31, 2026, which changed the ecosystem around it further.

LinkedIn. Effectively closed. Access is partner-only through a sales-led approval process. If you are not already an approved partner, treat it as unavailable for a new build.

Google for Jobs. Not a public API in the way people assume. It is an aggregator that surfaces structured data from across the web, and direct feed access was restricted to authorized ATS partners after Google’s 2025 indexing changes. You can benefit from it by publishing schema on your own listings, but you cannot query it as a data source.

And scraping any of these directly is against their terms, operationally fragile, and a maintenance burden that breaks every time a page layout shifts. It is not a foundation to build on.

The takeaway: the three names you would reach for first are the three you cannot use. Plan around that from day one.

The data layer: what actually works in 2026

Here are real, currently available options, grouped by how you get access.

A few notes that save time:

Start with Adzuna if you want a free path. It is a straightforward REST API returning listings and salary estimates, and the free tier is enough to build and validate a prototype before you spend anything.

import requests

resp = requests.get(
    "https://api.adzuna.com/v1/api/jobs/us/search/1",
    params={
        "app_id": "YOUR_APP_ID",
        "app_key": "YOUR_APP_KEY",
        "what": "python developer",
        "where": "remote",
        "results_per_page": 20,
    },
)
jobs = resp.json()["results"]   # [verify: response shape against current Adzuna docs]

Government and niche boards are underrated. USAJobs is a clean free API if US federal roles are in scope. Regional and remote-focused boards often expose feeds too. Narrow, reliable, and free beats broad and blocked.

Aggregator APIs are how you reach the blocked sources indirectly. Services that index public listings and return normalized JSON are the practical modern equivalent of the old Indeed API, without violating anyone’s terms yourself. They cost money at volume, so price them against your call pattern.

The pattern across all of them: you will almost certainly wire up more than one source, because no single legal, affordable API covers every market. Normalize their different response shapes into one internal schema early, or you will pay for it later.

The intelligence layer: the AI model APIs

Once postings are flowing, the AI model APIs do the work that makes the product worth using. This is a solved space, and the right choices are covered in depth in the companion guide on model selection. The short version:

Parsing and extraction. Turning a resume or a job description into structured fields. High volume, quality saturates early, so a cheap model with reliable structured output is correct. Frontier models add cost, not accuracy.

Matching. Ranking postings against a candidate. This is an embeddings problem, not a chat problem. Embed the postings once, embed the candidate, rank by similarity, and send only the shortlist to a chat model. Looping every posting through a chat model scales your cost linearly with your job database, which is the most common architecture mistake in this category.

Tailoring and writing. Cover letters and resume rewrites, the output a human reads and judges. Low volume, high stakes, so this is the one place a better model earns its cost.

The unit that matters here is cost per task, not the sticker price per token. A parsing call and a cover letter call have wildly different economics and should not run on the same model.

How the two layers fit together

A working pipeline looks like this:

1. Fetch postings from one or more data APIs.
2. Normalize their different shapes into one internal schema.
3. Extract structured requirements from each posting with a cheap model.
4. Embed postings and candidate profiles, store the vectors.
5. Match by similarity, shortlist the top results.
6. Assess and tailor the shortlist with a better model.

Steps 1 and 2 are the data layer. Steps 3 through 6 are the intelligence layer. The data APIs are external services you subscribe to. The model APIs are external services you call per token. Both are integrations you own, and both are where cost and reliability problems hide.

The problem you hit at step 3

Look at that pipeline again. You are now calling a cheap model for extraction, an embeddings model for matching, and a better model for tailoring. That is at least three model APIs, often across two or more providers, each with its own key, SDK, billing, and failure mode. Add a data API or two on top and you are managing five external integrations before the product does anything.

The data APIs you have to manage yourself, since no one consolidates job boards for you cleanly and legally. The model APIs are different. An AI API gateway puts every model behind one OpenAI compatible endpoint, so the three model calls in your pipeline become one integration with three model strings, one bill, and automatic failover when a provider drops.

To be clear about the boundary: a gateway is the intelligence layer, not the data layer. MixRoute gives you every major model through one endpoint with zero markup and automatic failover, which collapses steps 3 through 6 into a single integration. It does not supply job postings. You still bring a data source. What it removes is the part of the stack where you would otherwise juggle four model providers by hand, and the recurring theme across this whole build holds here too: watch your cost per task, and route the cheap work away from the expensive models.

MixRoute is built for exactly that layer: one OpenAI compatible API across [verify: model count] models, automatic failover, and zero markup on provider pricing. Smart routing, which picks the best model per request on quality, cost, and latency, is coming.

FAQ

What is a job search API? It refers to one of two layers. A job data API returns job postings you can query by keyword, location, or salary. An AI model API provides the intelligence to parse resumes, match candidates, and write tailored documents. A full job search product uses both.

Is there an Indeed API for job search? Not for reading job postings. Indeed deprecated its public Publisher API in 2023, and its remaining official APIs are employer-side only, built for ATS partners to publish jobs into Indeed. To access Indeed listings today, developers use third-party aggregator APIs that index public postings into normalized JSON.

What is the best free job posting API? Adzuna is the most practical free starting point, offering a REST API with global listings and salary data on a free tier. USAJobs is a free government API for US federal roles. For a prototype, either lets you build and validate before spending anything.

Can I use the LinkedIn API to get job listings? Generally no for a new build. LinkedIn access is partner-only through a sales-led approval process. If you are not already an approved partner, plan your architecture around other data sources.

What AI models should I use to build a job search tool? Cheap models with structured output for parsing and extraction, an embeddings model for matching, and a stronger model only for cover letters and rewrites that a human reads. Matching should use embeddings and similarity ranking, not a chat model looped over every posting.

Do I need multiple APIs to build a job search product? Almost always. You typically combine more than one job data source, since no single legal API covers every market, plus several model APIs for extraction, matching, and writing. Normalizing data sources into one schema and routing model calls through one gateway keeps that integration count manageable.

The bottom line

A job search API is two layers wearing one name. The data layer supplies postings, and the names you would reach for first, Indeed, LinkedIn, and Google, are dead or gated, so you build on Adzuna, government feeds, and aggregator APIs instead. The intelligence layer supplies the smarts, and there the rule is cheap models for what machines read, better models for what humans read, embeddings for matching.

Wire the data layer yourself from more than one source. Consolidate the model layer so you are not maintaining four provider integrations to run one pipeline.

MixRoute is the model layer: every major model behind one OpenAI compatible endpoint, automatic failover, zero markup. Bring your job data, and route the intelligence through one integration. Start building on MixRoute