Xing Jobs Lookup: xing jobs scraper from $1.5/1k

You write job searches the way you'd type them into XING — software engineer @ Berlin — and this actor runs each one against XING's own search results, read straight out of the page's server-rendered data, and returns one clean row per posting: title, company, location, employment type, pay range (when the advertiser discloses one), and a permanent link.

No login. No API key. XING's search-results page is a client-rendered app shell at first glance, but the very same HTML response it sends already carries the full result set — see "Why this one" below.

Who it's for

The accountable_eel catalogue sells company and hiring intelligence columns for outbound and recruiting. Each actor takes a list of identifiers — domains, company slugs, and here, job searches — and returns one flat, stably-named row per result: the shape a Clay table, an n8n workflow, or an AI agent can consume without post-processing. Pricing is pay-per-event: a fraction of a cent for a row you actually got, and nothing for a search that returns nothing at all.

This actor is the German-market counterpart to seek-jobs-search-lookup and linkedin-jobs-search-lookup: wide-net keyword + location search against XING, the professional network most widely used in Germany, Austria, and Switzerland, rather than a per-company listing. Recruiters and sales teams building a DACH-region candidate or lead list start here instead of scraping XING by hand.

Why this one

• Reaches data behind a client-rendered shell without a headless browser. XING's search-results page renders into an empty <div id="app"> — normally a sign you need a real browser — but the SAME initial HTML response also embeds a window.crate={...} script tag whose Apollo GraphQL cache is already populated with that exact search's results. This actor parses that inline cache directly: no Playwright, no proxy, no CAPTCHA-solving.
• Real location filtering. location=Berlin genuinely narrows results to that city — verified by checking every returned posting's own location field, not just trusting the parameter is accepted.
• You are never billed for the same posting twice. Every posting is deduplicated by its XING job ID across the pages of one search and, by default, across every search in the run.
• Honest about what XING's own search actually does. XING's search runs in SEMANTIC mode — confirmed directly in the page's own GraphQL query variables — meaning a search for nonsense keywords does not come back empty; it falls back to unrelated postings, the same way it would if you typed nonsense into XING's own search box. This actor cannot detect that fallback (XING gives it no signal to detect), so you should always set "Job title must contain" to your actual role keyword if precision matters to you — see the FAQ for what this means for your bill.
• No fabricated total-match count. XING's own search response reports total: -1 on every probe run — an internal placeholder, not a real number. Rather than presenting a made-up total, this actor simply doesn't have a totalAvailable column; morePagesAvailable tells you plainly whether this actor's own page cap was reached while XING still had more to give.

What you get

One row per job posting by default. (Turn off "One row per job posting" in the Input tab to get one row per search instead, with the whole posting list nested in jobs.) Every row carries these fields:

Field	Type / format	Description
query	text	The search line you passed in, unchanged.
found	boolean	true if the search returned at least one posting. false rows are never charged.
status	text	OK, NOT_FOUND (rare — see FAQ), BAD_FORMAT (the line had neither keywords nor a location), or BLOCKED.
searchKeywords	text	The keywords actually sent to XING.
searchLocation	text	The location actually sent to XING.
jobCount	number	How many postings this search returned after your filters — this is exactly what you're charged for.
morePagesAvailable	boolean	true if this actor's own page cap (5 pages, 100 postings) was reached while XING still had results to give — not a claim about how many more exist, since XING doesn't expose that number honestly (see "Why this one").
jobs	array	The full posting list. Present in every row; it's what gets expanded into separate rows in "one row per posting" mode.
jobId	text	XING's own numeric posting ID — stable, and what deduplication keys on.
title	text	Job title, as XING has it (mostly German-language postings).
company	text	Hiring company name, as XING displays it on the posting.
location	text	City XING lists for the posting.
remote	boolean	true if the location or title reads as remote — including the German "Home Office".
salaryText	text	A formatted pay range or single figure, built from XING's own salary data, when the advertiser (or XING's own estimate) discloses one. Empty when no salary information exists.
employmentType	text	XING's own wording for the employment type — typically German, e.g. "Vollzeit" (full-time) or "Teilzeit" (part-time).
postedAt	date (ISO)	XING's own "last refreshed" timestamp for this posting — not the original first-posted date; XING's search payload doesn't expose one. See the FAQ.
url	link	Permanent link to the posting on xing.com.
description	text	A short highlights summary built from XING's own key-responsibilities bullets, truncated to 500 characters. Empty on postings XING doesn't provide one for.
scrapedAt	date (ISO)	When this actor fetched the row.

A search that returns no postings at all comes back as a single found: false row with a status/message explaining why, and is never charged. So does a blank line. In practice this is rare for a keywords-only search — see the FAQ on XING's semantic fallback.

Pricing

• Job posting returned: $1.5 per 1,000 job postings

Plus a $0.00005 start fee per run. Each event above is billed independently, only when it actually returns data — misses (found:false) are never charged.

You're charged per posting returned, not per search — a search that returns 20 postings costs twenty, a genuinely empty search costs nothing, and a BAD_FORMAT line costs nothing.

Because you pay per posting, "Most postings to return per search" is your budget control: leave it at 20 (one page) and a ten-search run costs at most 200 postings' worth. This actor stops paging at 5 pages (100 postings) per search regardless, as a deliberate cost-control cap — see "Why this one" for why going deeper has diminishing value on a semantic search engine.

How to use

1. In the Apify Console. Open the actor page and click Start — the searches field is already pre-filled with a working example. Results land in the run's dataset as soon as each item is found.
2. Via the API. Call it directly with a POST request — no Console needed once you have an API token:

   curl "https://api.apify.com/v2/acts/accountable_eel~xing-jobs-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
     -X POST \
     -H "Content-Type: application/json" \
     -d '{"searches":["software engineer @ Berlin"]}'
   

3. On a schedule. Save this actor as an Apify Task with the input you want, then add a Schedule (hourly, daily, weekly) so it runs on its own — no server of your own required.

Paste one search per line:

software engineer @ Berlin
python
marketing manager @ Munich

A line with no @ location uses the location you set once in 🔍 Search settings — leave that blank too and the search covers everywhere XING has listings.

🔍 Search settings:

Input	What it does
defaultLocation	Location for any line that doesn't name one. Write it the way XING does — a city name, e.g. "Berlin".
maxJobsPerQuery	Most postings to return per search. Default 20 (one page), capped at this actor's own 100-posting depth limit.

🎯 Narrow the results — applied here, to the postings after they arrive, since XING's own semantic search doesn't reliably do this for you (see "Why this one"). They combine with AND across fields and OR within a field:

Input	What it does
titleKeywords	Keep only titles containing one of these — ["engineer","developer"]. Recommended on every search.
excludeTitleKeywords	Drop titles containing one of these — ["praktikum","werkstudent"] (internship, working student). Applied after the include list.
companies	Keep only these companies — partial names match.
excludeCompanies	Drop these companies — useful for filtering out recruitment agencies you already know.
locations	Narrow a wide search to particular cities or districts.
remoteOnly	Keep only roles whose location or title reads as remote, including "Home Office".
skipDuplicateJobs	On by default. Each posting is returned, and billed, once per run even if two searches overlap.

Input

{
  "searches": [
    "software engineer @ Berlin"
  ]
}

One search per line. Write it as "keywords @ location", or just the keywords and set a location below. Accepted formats: software engineer @ Berlin, python, marketing manager @ Munich.

Output

query	found	status	searchKeywords	searchLocation	jobCount	morePagesAvailable	jobs	jobId	title	company	location	remote	salaryText	employmentType	postedAt	url	description	scrapedAt
software engineer @ Berlin	true	OK	software engineer	Berlin	20	false	<all postings found (full list)>	157369813.d962f0	Senior Software Engineer	Capmo.com	Berlin	false	85,000–115,000 EUR	Full-time	2026-09-05T11:29:44Z	https://www.xing.com/jobs/berlin-senior-software-engineer-157369813	Design scalable backend services with Node.js. Architect APIs and distributed systems. Collaborate with frontend engineers on projects.	2026-09-08T17:43:39.353Z

A miss comes back as a row with "found": false and is never charged.

Use it from Clay, n8n, Make, or an AI agent

This actor runs synchronously over plain HTTP — call it directly from a script, a workflow tool, or an AI agent, no Apify Console needed once you have an API token.

curl "https://api.apify.com/v2/acts/accountable_eel~xing-jobs-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"searches":["software engineer @ Berlin"]}'

n8n. Add an HTTP Request node: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~xing-jobs-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body Content Type JSON, JSON Body {"searches":["software engineer @ Berlin"]} (swap in an expression from an earlier node for a real value).

Clay. Add an "HTTP API" column: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~xing-jobs-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body {"searches":["{{search}}"]}, mapping the row's search into the searches array.

MCP. In Claude, Cursor, or any MCP client with the Apify MCP server, ask for "Xing Jobs Scraper: Job Search API | Apify" — the agent will find and run this actor.

Tips

• Always set "Job title must contain" (titleKeywords) to your actual role keyword. XING's own search runs in semantic mode and does not reliably return an honest empty result for an off-target query — this filter is your real defense against paying for loosely related rows.
• Keep "Max concurrency" conservative on a large list of searches — XING has no observed hard block in testing, but this target has no browser fallback, so a site that starts blocking you costs more in wasted requests than a slower, steadier crawl.
• salaryText is populated only when the advertiser (or XING's own salary estimate feature) discloses one — expect it empty on a large share of postings, since most German job ads don't state pay.
• Use postedAt as a freshness signal, not a "first seen" date — it's XING's own last-refreshed timestamp, and a long-running listing can show a recent postedAt even though it first went live weeks earlier.

vs. alternatives

	What it costs	What you get	Trade-off
This actor (xing-jobs-lookup)	$0.0015 per posting returned (FREE tier, less on paid tiers), $0.00005 actor start, nothing for a genuinely empty search	One row per XING job posting — title, company, location, employment type, pay range and apply link, filterable by title keyword, company, location and remote	XING's own search is semantic, so an off-target query returns loosely related postings rather than an honest empty result — titleKeywords is the real fix. No first-posted date is available, only a last-refreshed timestamp.
shahidirfan/Xing-Jobs-Scraper	Community actor, 184 users in the last 30 days, rated 5.00 on 7 reviews	Also scrapes XING job search results	An established incumbent with review history; this actor is new and prices per posting rather than however that one bills.
Doing it yourself	Your time + reverse-engineering XING's inline Apollo GraphQL cache, handling the semantic-search relevance problem, and re-testing when XING's frontend bundle changes	The same data	This actor's cache-extraction, dedup, and relevance-filtering logic is the maintenance burden it absorbs.

Prices for third-party tools are as researched in September 2026 and are not tracked here — check the vendor before relying on the comparison.

FAQ

Why did my search return jobs that don't match my keywords at all? XING's own search runs in SEMANTIC mode (confirmed in the page's own GraphQL query variables) — it is designed to find "related" postings, not exact keyword matches, and for a query it can't match well it falls back to generic, unrelated postings rather than an honest empty result. This actor passes your keywords straight to XING and cannot detect or override that behavior. Set titleKeywords to your actual role keyword to filter the results down to what you actually want — see "Tips" above.

Am I charged for irrelevant rows XING's semantic fallback returned? Only for rows that pass your filters. If you don't set titleKeywords, yes — every row XING returns is billed, since this actor has no way to know a row is "irrelevant" that XING itself doesn't also expose. This is disclosed here deliberately rather than silently.

Why is postedAt sometimes recent for a posting that's clearly been up a while? XING's search payload does not include a first-published date anywhere this actor found — postedAt is XING's own "last refreshed" timestamp instead, which can move well after a posting first went live. Treat it as a freshness/recency signal, not a "posted N days ago" figure.

Is morePagesAvailable a real count of remaining postings? No, and this actor deliberately doesn't offer one. XING's own search response reports total: -1 on every probe run — an internal placeholder, not a real total. morePagesAvailable only tells you this actor's own 5-page cap was reached while XING was still returning postings.

Does this handle rate limits or blocking? Each request goes through Apify's proxy configuration and retries up to twice on failure. A BLOCKED status means XING returned HTTP 403, 429, or 503 — lowering "Max concurrency" can help; no proxy has been needed for this target as of the last live check.

Do I need to configure proxies? No. The actor uses Apify's default proxy configuration out of the box; XING's search endpoint has not required anything beyond a plain HTTP request in testing.

Is this GDPR-relevant? The data returned is business/professional information already published publicly by employers on XING's job board (job title, company, location, pay range) — not personal data about private individuals.

Can I schedule this to re-check the same searches on a cadence? Yes — set up an Apify Task with a schedule and point it at this actor with a saved input. skipDuplicateJobs keeps a single run's overlapping searches from double-billing, but each scheduled run is independent — a role that appeared in yesterday's run will appear again today if it's still listed.

Can an AI agent call this directly? Yes. It's registered on the Apify MCP server — an agent in Claude, Cursor, or another MCP client can find and run it by name ("Xing Jobs Scraper: Job Search API | Apify"), or you can call the REST endpoint shown above from any script or workflow tool.

Related actors

• SEEK Jobs Search Lookup — the same keyword + location search shape, against Australia's largest job board.
• LinkedIn Jobs Search Lookup — the global equivalent, against LinkedIn's guest job search.
• Company Domain Enrichment — broader firmographic and hiring-activity enrichment once you know which companies to target.