# Xing Jobs Lookup: xing jobs scraper from $1.5/1k (`accountable_eel/xing-jobs-lookup`) Actor

Run keyword + location job searches on XING, the leading German-language professional network, and get one row per posting: title, company, location, employment type, pay range and an apply link. No login. Pay per posting returned; a blocked search is free.

- **URL**: https://apify.com/accountable\_eel/xing-jobs-lookup.md
- **Developed by:** [Adrian Voss](https://apify.com/accountable_eel) (community)
- **Categories:** Jobs, Lead generation
- **Stats:** 1 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $0.75 / 1,000 job posting returneds

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## 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:
   ```bash
   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

```json
{
  "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.

```bash
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](https://apify.com/accountable_eel/seek-jobs-search-lookup) — the same
  keyword + location search shape, against Australia's largest job board.
- [LinkedIn Jobs Search Lookup](https://apify.com/accountable_eel/linkedin-jobs-search-lookup) —
  the global equivalent, against LinkedIn's guest job search.
- [Company Domain Enrichment](https://apify.com/accountable_eel/company-domain-enrichment) —
  broader firmographic and hiring-activity enrichment once you know which companies to target.

# Actor input Schema

## `searches` (type: `array`):

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. You're only charged for the ones we actually find — a miss costs nothing.

## `testRun` (type: `boolean`):

Turn this on to test your input on a small sample before running the full list. Turn it off to process everything.

## `onlyFound` (type: `boolean`):

Only keep rows where something was actually found. Misses are always free, whether or not you show them here.

## `includeKeywords` (type: `array`):

Optional. Only keep results that mention at least one of these words (e.g. a job title, a city, a product name). Leave empty to keep everything.

## `excludeKeywords` (type: `array`):

Optional. Drop any result that mentions one of these words. Leave empty to skip nothing.

## `maxResults` (type: `integer`):

Optional. Stop the run once this many results have been found — useful for a quick, cheap sample. Leave blank for no limit.

## `defaultLocation` (type: `string`):

Used for any line that's just keywords. Write it the way XING does — a city name, e.g. "Berlin", "Munich", "Hamburg". Leave empty to search everywhere.

## `maxJobsPerQuery` (type: `integer`):

XING hands out 20 postings per page and this actor stops at 5 pages (100 postings) as a cost-control cap — XING did not show an observed depth limit in testing, but paying for more pages of an increasingly semantic-fallback result set has diminishing value. You pay per posting returned, so this is also your budget control.

## `titleKeywords` (type: `array`):

Optional. Keep only roles whose title contains at least one of these words. Case doesn't matter and partial words work. Leave empty to keep every role. Recommended: XING's own search is semantic and can return loosely related postings (see FAQ) — this filter is your real control over relevance.

## `excludeTitleKeywords` (type: `array`):

Optional. Drop any role whose title contains one of these words. Applied after the include list above, so a role matching both is dropped.

## `companies` (type: `array`):

Optional. Keep only roles at companies whose name contains one of these. Partial matches work.

## `excludeCompanies` (type: `array`):

Optional. Drop roles at companies whose name contains one of these — handy for filtering out recruitment agencies you already know.

## `locations` (type: `array`):

Optional. Narrow a wide search down to particular cities or districts. Applied to the location XING prints on each posting.

## `remoteOnly` (type: `boolean`):

Keep only roles whose location or title reads as remote (including the German "Home Office"). Applied to the postings after they arrive — treat it as a strong filter, not a guarantee.

## `skipDuplicateJobs` (type: `boolean`):

On by default. Overlapping searches routinely surface the same role — with this on, each posting is returned, and billed, exactly once per run.

## `columns` (type: `array`):

Choose which pieces of information to include in each result row. All are included by default.

## `expandRows` (type: `boolean`):

When on, each job posting found gets its own row instead of being grouped under its search. You're still only charged once per search, no matter how many rows it produces.

## `maxConcurrency` (type: `integer`):

Parallel requests. Keep conservative — this target has no browser fallback, so getting blocked costs more than slow-and-steady.

## `proxyConfiguration` (type: `object`):

Apify Proxy config. Residential recommended for anti-bot-sensitive targets.

## Actor input object example

```json
{
  "searches": [
    "software engineer @ Berlin"
  ],
  "testRun": false,
  "onlyFound": false,
  "includeKeywords": [],
  "excludeKeywords": [],
  "defaultLocation": "",
  "maxJobsPerQuery": 20,
  "titleKeywords": [],
  "excludeTitleKeywords": [],
  "companies": [],
  "excludeCompanies": [],
  "locations": [],
  "remoteOnly": false,
  "skipDuplicateJobs": true,
  "columns": [
    "searchKeywords",
    "searchLocation",
    "jobCount",
    "morePagesAvailable",
    "jobs",
    "jobId",
    "title",
    "company",
    "location",
    "remote",
    "salaryText",
    "employmentType",
    "postedAt",
    "url",
    "description"
  ],
  "expandRows": true,
  "maxConcurrency": 5,
  "proxyConfiguration": {
    "useApifyProxy": true
  }
}
```

# Actor output Schema

## `results` (type: `string`):

No description

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "searches": [
        "software engineer @ Berlin"
    ],
    "includeKeywords": [],
    "excludeKeywords": [],
    "titleKeywords": [],
    "excludeTitleKeywords": [],
    "companies": [],
    "excludeCompanies": [],
    "locations": []
};

// Run the Actor and wait for it to finish
const run = await client.actor("accountable_eel/xing-jobs-lookup").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "searches": ["software engineer @ Berlin"],
    "includeKeywords": [],
    "excludeKeywords": [],
    "titleKeywords": [],
    "excludeTitleKeywords": [],
    "companies": [],
    "excludeCompanies": [],
    "locations": [],
}

# Run the Actor and wait for it to finish
run = client.actor("accountable_eel/xing-jobs-lookup").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "searches": [
    "software engineer @ Berlin"
  ],
  "includeKeywords": [],
  "excludeKeywords": [],
  "titleKeywords": [],
  "excludeTitleKeywords": [],
  "companies": [],
  "excludeCompanies": [],
  "locations": []
}' |
apify call accountable_eel/xing-jobs-lookup --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,accountable_eel/xing-jobs-lookup"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/ZxKHyHVVjgSHdaEXs/builds/xiMwPVHEQdRxNmR41/openapi.json