Free XML Job Feeds: What Actually Still Works in 2026

Search "free XML job feed" and you'll find a decade of blog posts telling you to grab a feed from a .jobs domain, or pointing at whatever ATS happens to publish a schema. Most of that advice is stale. We went and checked what's actually live in 2026 — two real, actively-maintained feeds with real access processes (iCIMS and Indeed), one once-real trick that appears to have quietly died, one source that's genuinely open with no approval process at all but isn't what most people mean by "XML feed" (USAJobs), and one that's both genuinely open and actually XML: jobr.pro's feed.xml.

The Trick That Stopped Working: `.jobs` Domain Feeds

The advice going back to at least 2017: DirectEmployers' .jobs-domain network (workintexas.jobs, newyork.jobs, and similar city/state/industry microsites) exposed a /feed/xml URL at the bottom of each site, no signup required. That was real once.

We checked it in 2026: DirectEmployers as an organization is still active, but the flagship site (dejobs.org) no longer has a per-job XML feed link in its footer — only a generic organizational RSS feed, unrelated to job listings. Individual legacy .jobs microsites are inconsistent; some don't resolve at all anymore. If you find a still-working one, treat it as a bonus, not a foundation — this isn't a source to build a product around in 2026.

The One That's Real: iCIMS's Standard XML Feed

iCIMS (a large ATS platform) documents a genuine, current XML feed spec for job boards. The schema, field by field:

<source>
  <publisher>Acme Careers</publisher>
  <publisherurl>https://careers.acme.com</publisherurl>
  <JobPosting>
    <referenceId>123456</referenceId>
    <url>https://careers.acme.com/job/123456?...</url>
    <title>Senior Backend Engineer</title>
    <description>Combined Overview, Responsibilities, and Qualifications sections</description>
    <datePosted>2026-07-01</datePosted>
    <validThrough>2026-08-01</validThrough>
    <jobType>Permanent Full Time</jobType>
    <hiringOrganization>Acme Inc</hiringOrganization>
    <city>San Francisco</city>
    <state>CA</state>
    <country>US</country>
    <postalCode>94105</postalCode>
    <streetAddress>123 Market St</streetAddress>
    <other>Requisition ID, positions count, and other Job Header fields</other>
  </JobPosting>
  <!-- repeated per posting -->
</source>

What's worth knowing before you build around it:

referenceId — the stable per-job identifier, assigned by iCIMS. Safe dedup key.
description — pre-combined from the posting's Overview, Responsibilities, and Qualifications sections into one field. You don't get those sections separately.
validThrough — included only when the employer set a real expiration; treat its absence as "no known close date," not as an error.
Location is genuinely structured (city, state, country, postalCode, streetAddress) — better than most ATS public APIs, which hand you one free-text string.
No salary fields anywhere in the schema. If you need compensation data, this feed can't give it to you, full stop — there's nothing to parse around.

The access process is the part "free" undersells. This isn't a public URL you can curl. You have to apply as a job-board vendor, and once approved, you authenticate via OAuth2 with a client_id/client_secret issued for test and production environments separately. The feed itself is delivered as a zipped XML file (commonly 200–500+ MB for a large customer base), refreshed three times a day starting at 8am ET, named {vendorName}-job-postings.zip. Individual employers can also opt out of being included via their own iCIMS settings — so even once you're approved, coverage isn't guaranteed to include every iCIMS customer.

So "free" here means no dollar cost, not no gatekeeping — it's a real application-and-approval flow, closer in shape to Indeed's own partner program (below) than to a walk-up public API.

Also Real (and Still Alive): Indeed's XML Feed

Indeed has a documented Job Sync XML feed too, and it's worth being precise about its status, because the search results for "is Indeed XML dead" are genuinely mixed. Some partner-facing announcements (visible via SAP SuccessFactors' own support documentation) describe Indeed discontinuing "single-source feeds" for organic postings on a March 31, 2026 deadline. Taken at face value, that reads like the whole format is being killed.

It isn't. Indeed's own XML feed reference documentation was still being actively updated as of March 2026 — new elements added, new market support (Japan) shipped — which isn't what a deprecated spec looks like. The more accurate read: Indeed is steering new integrations toward its GraphQL Job Sync API ("use the Job Sync API instead of an XML integration," per Indeed's own FAQ) and has been sunsetting specific legacy delivery arrangements for certain partners — confirmed for SAP SuccessFactors customers specifically — not retiring XML as a format outright.

Same caveat as iCIMS applies here too: this is an inbound feed, for submitting job postings into Indeed, not a way to retrieve Indeed's listings out. See the full Indeed comparison — Indeed hasn't had a public listings-retrieval API of any kind since its Publisher API was deprecated in 2023, XML or otherwise.

This is also exactly why so much old "free Indeed API" advice still circulates. Indeed's Publisher API — before it was deprecated — was genuinely a free, self-serve, API-key-registration endpoint for pulling Indeed's own listings out, and it defaulted to XML output (JSON was available too, but XML was what you got if you didn't specify a format). Key issuance stopped around 2023–2024. Any tutorial or blog post describing "Indeed's free XML job feed" as something you can register for and consume today is describing that dead program, not the current inbound-only Job Sync feed covered above.

The One That's Actually Open: USAJobs

If what you actually want is zero-approval, self-serve access, the closest real thing isn't an XML feed at all — it's the USAJobs API, the official REST API for USAJOBS.gov, operated by the US Office of Personnel Management. Register at developer.usajobs.gov with just an email address, and you get an Authorization-Key back immediately — no application review, no waiting period, no tiering. Every request needs two headers: User-Agent (the email you registered with) and Authorization-Key.

The catch, and it's a real one: it's US federal government job listings only, returned as JSON (an RSS/XML export option exists alongside the primary JSON API, but the main interface isn't the XML schema people usually mean by "job feed"). If your product needs private-sector listings, this doesn't cover you — but if you specifically need federal postings, it's the rare source in this category that's both free and genuinely unrestricted.

If you need private-sector coverage with that same no-approval simplicity, Adzuna's Search API is the closer match — also free, also instant registration, also JSON rather than XML, just aggregator-sourced rather than direct from employers.

The One That's Both Open and Actually XML: jobr.pro

Everything genuinely open so far has been JSON (USAJobs, Adzuna), and everything genuinely XML so far has been gated (iCIMS, Indeed). jobr.pro's feed.xml is the one source in this roundup that's actually both: a real XML feed, publicly accessible, no key, no approval process.

curl "https://jobr.pro/feed.xml?role=engineer&location=US&limit=100"

Three params — role (free text), location (not free text: a fixed 19-country allowlist, matched by name or ISO2 code, silently falling back to all 19 if nothing matches — no error), limit (up to 500) — an hourly-refreshed rolling 14-day window of postings, and one detail worth knowing before you build around it: applyUrl is never the real employer application link — every job points to a jobr.pro redirect route (/r/{id}) that resolves the real destination server-side, so the real URL never appears in the static XML itself. No salary field, no structured location (a single display string, same limitation as iCIMS's feed). Full field-by-field breakdown, including exactly how that redirect mechanism and the country allowlist work, in the dedicated guide.

The Real Pattern Across All of These

Line them up and a pattern shows up that the "just grab a free feed" framing hides:

Coverage is fragmented. iCIMS gets you iCIMS customers who haven't opted out. Indeed's feed is inbound-only and gets you nothing to retrieve. USAJobs gets you federal roles. jobr.pro gets you one job board's own listings. None of them get you Greenhouse-, Lever-, Ashby-, or Workable-hosted postings — you'd need a separate integration per source, each with its own schema, access model, and refresh cadence.
"Free" usually means "no dollar cost," not "no process" — with jobr.pro the real exception here. iCIMS's feed requires vendor approval and OAuth2 setup before you see a single job. Indeed's requires a signed Developer Agreement and roughly a six-week review (see the full Indeed comparison). jobr.pro's is the one that's actually just a URL you can request right now.
None of them agree on a schema. iCIMS uses <referenceId>/<hiringOrganization>; jobr.pro uses <job>/<applyUrl>; USAJobs uses its own JSON field names; a Greenhouse or Lever API (see how to scrape Greenhouse) uses yet another shape entirely. Every source you add is its own parser, its own location-normalization problem, and its own dedup logic against everything else you're already ingesting.
Salary and location are usually the weakest fields, same as with ATS APIs — iCIMS and jobr.pro both have no salary field at all; structured location is the exception (iCIMS only), not the rule.

When This Is Enough

If you need exactly one of these sources — federal jobs via USAJobs, or iCIMS-hosted listings once you're an approved vendor — integrating it directly is completely reasonable, and neither costs you anything beyond engineering time.

When It Isn't

The moment you need broad coverage across multiple sources — some ATS-hosted, some feed-based, some structured, some not — you're maintaining a parser and a schema-reconciliation layer per source, with no shared salary or location normalization between any of them. That's the same problem normalizing four ATS platforms into one schema solves for direct ATS APIs — a normalized data API like CleanJobData gives you one consistent schema across sources instead of a growing pile of one-off XML and JSON parsers, with structured location and parsed salary fields built in rather than absent.

Test it with live job data in the CleanJobData Playground or explore the API Documentation.

The Trick That Stopped Working: .jobs Domain Feeds