What are the ways to get Indeed job-postings data?
There are four realistic routes to Indeed job-postings data, and they differ mostly in who does the maintenance and how you pay. This page lays them out honestly, including when RolesAPI is the wrong choice.
Option 1: Official Indeed APIs
Indeed’s public Publisher job-search API — the one that used to let third parties query postings — was deprecated and is no longer open to new integrations. The official APIs that remain, such as Job Sync and Indeed’s GraphQL surface, serve the hiring side: employers and applicant-tracking systems pushing jobs into Indeed and managing applications. They are not designed for pulling postings data out, and access is gated on partner agreements oriented around recruiting workflows.
Practical consequence: as of today there is no official, general-purpose API for reading Indeed postings. Every route below is a third-party approach to that gap.
Option 2: DIY scraping infrastructure
Providers in this category (Bright Data-class tools) sell the building blocks — proxy networks, browser automation, unblocking layers — and you assemble the pipeline. You write the collection logic, parse the pages into your own schema, handle layout changes when they break your parser, and manage blocks, retries, and job scheduling yourself.
This is the maximum-control option: any site, any field, your rules. It is also an ongoing engineering commitment, not a one-time setup — the pipeline is code you own and operate. Pricing is typically usage-based on traffic or successful requests, and predicting monthly cost takes some experience. It makes sense for teams with dedicated data-engineering capacity collecting from many sources at once.
Option 3: Multi-source aggregators
Aggregators continuously collect postings from many job boards and sell access to the combined, deduplicated feed — often with enrichment such as normalized titles or company matching. If you need cross-board market coverage (not just Indeed), this is the category that delivers it.
The trade-offs: contracts are typically enterprise-shaped — sales calls, annual commitments, per-seat or volume pricing — and the data model is the aggregator’s, updated on the aggregator’s schedule. For a team that just needs Indeed postings on demand, an aggregator is usually more product, more contract, and more cost than the job requires.
Option 4: RolesAPI
RolesAPI is a REST API for Indeed job-postings data: you call an endpoint, you get a normalized JSON role object. There is nothing to run — no proxies, no parsers, no maintenance when page layouts change. It is also agent-ready out of the box: an MCP server, OpenAPI spec, and llms.txt let AI agents use it without custom integration.
Pricing is per answer: 1 credit per role detail or search page, with 100 free credits (no card), a $5/month plan with 1,000 credits, and an annual plan at $54/year with 12,000. You can see real cost from the credit math before you commit to anything.
How do the options compare?
| Official Indeed APIs | DIY scraping infrastructure | Multi-source aggregators | RolesAPI | |
|---|---|---|---|---|
| Setup effort | N/A for reading postings | High — build the pipeline | Medium — contract, then integrate their feed | Low — one REST call |
| Maintenance | — | Yours: parsers, blocks, breakage | Vendor’s | Vendor’s |
| Pricing model | — | Usage-based on traffic/requests | Enterprise contracts | Per-answer credits, from $5/mo |
| Agent-readiness | — | None — you build tooling | Varies, generally API-only | MCP server, OpenAPI, llms.txt |
| Data shape | — | Whatever you parse | Vendor’s cross-board schema | Normalized Indeed role JSON |
| Source coverage | — | Anything you build for | Many boards | Indeed only |
When should you NOT use RolesAPI?
- You need multi-source coverage. RolesAPI covers Indeed’s country editions only. If your product depends on aggregating many job boards into one feed, an aggregator (option 3) is the right tool.
- You need candidate or resume data. RolesAPI serves publicly available job-postings data only — no resumes, no candidate profiles, no application data. Recruiting-side workflows belong with Indeed’s own hiring APIs.
- You need fields we do not return. Our role object is fixed and documented (see it here). If you need something outside it, a DIY pipeline is the only way to define your own schema.
If what you need is Indeed postings, normalized, on demand, with per-answer pricing — start with the free 100 credits.