Licensed Job Export Intelligence

Turn job records you own or are licensed to process into evidence, freshness, review priority, and safe next actions—without scraping, logins, or network requests.

Commercial result unit: one delivered licensed job export intelligence row. The automatic Actor start event is separate. Invalid records, duplicates, legacy scraper settings, and migration diagnostics do not intentionally emit result-found.

This product accepts a bounded job export supplied by the buyer. It does not visit XING or any other job board, follow a recorded URL, call an ATS, use a credential, or enrich a person. That boundary is the product: the Actor gives an authorized operator a consistent analysis and delivery contract without acquiring third-party content on the operator’s behalf.

What you get

Each valid unique job record can produce one Dataset row with stable source/job identity, legacy-compatible job fields, supplied-source provenance, freshness, confidence and concrete gaps, a review priority, an evidence-bound next action, safeToAutomate:false, and settlement-neutral billing intent. Actual delivery and charge facts live only in the current-run KVS OUTPUT receipt.

The Actor preserves familiar fields such as url, job_id, title, company, company_url, location, country, employment_type, posted_date, salary_raw, description, source_board, and scraped_at. New fields are additive: recordType, stableId, observedAt, freshness, change, confidence, evidence, recommendedAction, priority, safeToAutomate, failureDiagnostics, billing, sourceLicense, sourceRetrievedAt, requestDigest, and inputDigest.

What it does not give you

• no source scraping, sitemap walk, browser automation, login, or URL fetch;
• no proof that the buyer’s licence statement is legally sufficient;
• no verification that a vacancy is open, genuine, current, or approved by an employer;
• no identity lookup, candidate profiling, application, outreach, or CRM write;
• no salary normalization, language translation, skills inference, or ranking by protected traits;
• no autonomous hiring or rejection decision;
• no cross-run change detection from a single submitted snapshot.

Who uses it

Employers and talent operations

An employer can submit records exported from its own ATS or careers system and receive a consistent review table. This is useful when records originate from several internal teams and need one evidence vocabulary before editorial, compliance, or publishing review.

Licensed data providers

A provider with downstream processing and delivery rights can attach its source label and licence statement to every record. The Actor preserves those statements as buyer-attested evidence; it does not independently validate the contract.

Agencies

An agency may process a client export only when its agreement covers that purpose. Use separate runs for separate clients, remove unnecessary personal data, and delete outputs when the purpose ends.

Data governance teams

Reviewers get deterministic input, duplicate, invalid, delivered, paid, free, withheld, unknown, partial, fatal, and replay counters. That makes the run auditable without pretending the underlying content was independently verified.

Poor-fit users

Do not use this Actor to crawl XING, scrape job boards, bypass access controls, harvest recruiter details, infer sensitive traits, automate employment decisions, or send unsolicited messages.

How to run

1. Export only records you are authorized to process.
2. Remove secrets, private notes, candidate data, tracking tokens, and unnecessary prose.
3. Select the exact rights confirmation.
4. Submit one to 100 job objects.
5. Read the Dataset rows and the current-run OUTPUT together.
6. Verify the source record and evidence gaps before any business action.

{
  "schemaVersion": "2.0",
  "authorization": "I confirm I am authorized to process and deliver these job records",
  "sourceContext": "buyer_licensed_export",
  "jobs": [
    {
      "jobId": "job-101",
      "url": "https://jobs.example.com/job-101",
      "title": "Senior Data Analyst",
      "company": "Example GmbH",
      "location": "Berlin",
      "country": "DE",
      "employmentType": "Full-time",
      "postedDate": "2026-08-12T10:00:00Z",
      "sourceName": "Licensed ATS export",
      "sourceLicense": "Buyer confirms downstream processing and delivery rights"
    }
  ]
}

The example domains are placeholders. The Actor records URLs but never opens them.

Pricing

The primary pricing noun is licensed job export intelligence row.

On the FREE service tier, the automatic Actor start event is $0.005 and one result-found event is $0.003. Volume tiers reduce both prices. The Store pricing table is authoritative for the buyer’s current tier.

A result event is requested only through the same linked Dataset push that delivers one valid unique job row. Delivery is serialized. Before each push, the Actor proves that the named result counter equals the number already confirmed in this run. After the push returns, it requires an exact +1 named-counter delta and a bounded aggregate receipt.

Free diagnostics use an unnamed Dataset push. The Dataset item event must remain unpriced. A free row explains legacy input or rejected records; it is not a paid vacancy.

The buyer’s charge cap is evaluated in integer microdollars. Unlimited platform caps remain unlimited. A finite cap stops work before the next paid push when it cannot cover another result. The Actor never retries an ambiguous post-push operation.

Settlement states

State	Dataset delivery	Named charge	Replay
confirmed_paid	confirmed	exact +1	do not replay blindly
confirmed_free	confirmed	zero	do not replay blindly
unknown_delivery	unknown because push threw	unknown	no retry; reconcile manually
settlement_unknown	confirmed because push returned	unknown	no retry; reconcile manually
settlement_anomaly	confirmed	contradictory	no retry; investigate
pre_push_failed	not attempted	none	technically replay-safe after fixing cause

Input contract

The public contract is closed: unknown top-level and job properties are rejected. schemaVersion is 2.0. A paid record requires jobId, an HTTPS url, nonblank title, sourceName, and sourceLicense. Optional values remain nullable rather than invented.

Field	Rule
authorization	exact rights-attestation enum
sourceContext	buyer licensed export, employer feed, ATS export, or other authorized source
jobs	1–100 objects
jobId	nonblank, at most 160 characters; dedupe key within a source label
url	recorded HTTPS URL, at most 500 characters; never fetched
title	required, at most 300 characters
company	optional, at most 300 characters
companyUrl	optional recorded HTTPS URL; never fetched
postedDate	optional strict UTC ISO timestamp
validThrough	optional strict UTC ISO timestamp
description	optional, at most 4,000 characters
sourceName	required buyer-supplied source label
sourceLicense	required buyer-supplied rights statement
sourceRetrievedAt	optional strict UTC ISO timestamp

Legacy max_items, freshness_days, keyword_filter, fetch_full_description, and sitemap_override_url remain accepted only for migration. They never trigger a network request. A legacy-only input receives one free diagnostic telling the caller to submit licensed records in jobs.

Duplicate valid records share the same case-insensitive jobId; the first is kept and later duplicates are counted. Invalid records are counted and omitted. The request digest binds normalized accepted records, not raw property order.

Happy, partial, and failure output

Happy Dataset row

Local accepted-fixture binding:

{"runId":"local-test-xing-export-run","buildId":"local-checkpoint","status":"SUCCEEDED","evidenceAccepted":true}

{
  "schemaVersion": "2.0.0",
  "recordType": "licensed_job_export_intelligence",
  "stableId": "sha256:…",
  "found": true,
  "url": "https://jobs.example.com/job-101",
  "job_id": "job-101",
  "title": "Senior Data Analyst",
  "company": "Example GmbH",
  "location": "Berlin",
  "country": "DE",
  "posted_date": "2026-08-12T10:00:00.000Z",
  "source_board": "Licensed ATS export",
  "priority": "HIGH",
  "safeToAutomate": false,
  "billing": {
    "billingEligible": true,
    "billingIntent": "linked_push_result_found",
    "eventName": "result-found",
    "unit": "one delivered licensed job export intelligence row",
    "settlementSource": "current_run_kvs_output"
  }
}

The Dataset row states eligibility and intent, not final payment. Read OUTPUT for the current run’s settlement.

Happy current-run OUTPUT

Local terminal-fixture binding:

{"runId":"local-test-xing-export-run","buildId":"local-checkpoint","status":"SUCCEEDED","evidenceAccepted":true}

{
  "schemaVersion": "2.0.0",
  "kind": "licensed_job_export_intelligence_output",
  "status": "COMPLETE",
  "runId": "CURRENT_PLATFORM_RUN_ID",
  "input": {"requestedCount": 1, "uniqueCount": 1, "duplicateCount": 0, "invalidCount": 0, "legacyInputCount": 0},
  "run": {"attemptedCount": 1, "successfulCount": 1, "failedCount": 0, "deliveredRowCount": 1, "paidRowCount": 1, "freeRowCount": 0, "withheldRowCount": 0, "unknownDeliveryCount": 0, "unknownSettlementCount": 0, "partial": false, "budgetStopped": false, "fatalError": null, "replaySafe": false, "safeToAutomate": false},
  "delivery": {"eventName": "result-found", "attemptedPushCount": 1, "resultChargeCountBefore": 0, "resultChargeCountAfter": 1, "confirmedEventDelta": 1, "confirmedDatasetWrites": 1, "lastAttempt": {"state": "confirmed_paid"}},
  "errors": [],
  "terminal": {"outcome": "COMPLETE", "failureStage": null, "primaryKvsWrite": "confirmed", "recoveryKvsWrite": "not_attempted", "exit": "requested"}
}

Dynamic fields and the complete lastAttempt are omitted above only for readability. The actual receipt is closed and validated in full.

Partial output

A run becomes PARTIAL when it delivers a migration diagnostic, rejects some records, reaches a finite result cap, or confirms a free result settlement. Partial does not mean “probably complete”; inspect every count and error.

Failure output

Pre-delivery pricing, run identity, input, free-diagnostic, or KVS failures produce a failed receipt when the output store remains writable. Post-push uncertainty is fatal and sets replaySafe:false. If both primary and recovery KVS writes fail, platform run status and logs are the fallback evidence.

Field dictionary

Identity and legacy compatibility

stableId is SHA-256 of source label plus job ID. job_id preserves the supplied identity. url and company_url are recorded references, not verified URLs. scraped_at remains for compatibility but now means processing time; no scraping occurs. source_board preserves the supplied licensed-source label.

Evidence and time

observedAt is current-run processing time. sourceRetrievedAt is buyer supplied. freshness uses only supplied postedDate; absent or future dates become unknown. change.status is always not_measured for a single snapshot. evidence binds the normalized row and rights statement with SHA-256 digests. A digest is integrity evidence, not anonymization or source verification.

Decision fields

priority is a deterministic review route, not candidate or employer quality. Fresh records with company context route HIGH; non-stale incomplete records route MEDIUM; stale records route LOW. recommendedAction always requires verification in the authorized source. safeToAutomate is always false.

Failure and billing

failureDiagnostics distinguishes free migration/input diagnostics. billing describes eligibility and intended named event. KVS OUTPUT is authoritative for current-run delivery, payment, unknown state, partial work, fatal error, and replay safety.

Evidence and boundaries

The Actor can prove record-shape validation, deterministic normalization, duplicate handling, digest computation, current-run identity, Dataset push attempt, named-event movement, aggregate receipt shape, terminal KVS writes, and its own decision rules.

It cannot prove source ownership, contract scope, copyright permission, vacancy existence, employer intent, posting freshness beyond the supplied timestamp, salary accuracy, completeness, applicant fit, discrimination compliance, or downstream system compatibility.

Privacy

Submit job records, not candidate profiles. Remove recruiter phone numbers, personal email addresses, application notes, access tokens, signed URLs, and sensitive personal data. Apify Input and Dataset storage persist until deleted under the account’s retention settings. The buyer controls purpose, access, retention, correction, and deletion.

Security

The Actor performs zero network requests. Recorded URLs cannot create SSRF because they are never opened. Still remove credentials and tracking tokens from URLs because the string is stored in Input and Dataset. Restrict Actor runs and storage to authorized team members.

Decision routing

HIGH means “review promptly,” not “automatically act.” MEDIUM means context is usable but incomplete. LOW means stale or materially incomplete evidence should remain baseline material until refreshed. Confidence measures evidence completeness under the closed contract; it is not probability that a job is genuine.

Every downstream decision should verify the record in an authorized system, inspect gaps, apply employment and privacy rules, and preserve a human approver. Never use these fields to rank, accept, reject, or profile people.

Commercial playbooks

Employer publishing review

Export a small batch from the employer’s own ATS, remove candidate data, run the Actor, and route HIGH rows to a publishing reviewer. Verify title, location, validity, and application path in the ATS before publication.

Licensed feed quality review

Run one source per batch. Group diagnostics and LOW-confidence rows by missing field. Feed corrections back to the licensed provider rather than silently filling values.

Multi-system migration

Use stableId, requestDigest, and inputDigest for traceability. Treat proposed actions as review tasks. Confirm the destination schema separately; this Actor does not inspect ATS or CRM schemas.

Weekly governance sample

Select a bounded sample, document purpose and licence, run once, inspect KVS reconciliation, review gaps, export only needed fields, then apply retention policy. A new run is a new paid operation and is not an idempotent replay.

Integration recipes

Apify API

curl -X POST 'https://api.apify.com/v2/acts/zinin~xing-jobs/runs?waitForFinish=180&maxTotalChargeUsd=0.008' \
  -H 'Authorization: Bearer YOUR_APIFY_TOKEN' \
  -H 'Content-Type: application/json' \
  --data @input.json

Retrieve Dataset rows through the run’s defaultDatasetId. Retrieve the authoritative receipt through defaultKeyValueStoreId at key OUTPUT. Do not infer payment from Dataset billingEligible.

Task and schedule

Store only non-secret authorized input in a Task. Schedules create new runs and new start charges; use them only when a fresh export is intentionally supplied. The Actor does not monitor a source by itself.

Webhook

On terminal run status, fetch OUTPUT, require current run ID, inspect status, terminal, run.replaySafe, unknown counters, and exact result delta, then fetch Dataset rows. Never auto-rerun unknown_delivery, settlement_unknown, or settlement_anomaly.

Spreadsheet or warehouse

Flatten only the fields needed for the approved purpose. Keep stableId, source label, licence statement, freshness, confidence gaps, safe-to-automate, and request digest with every exported row.

MCP or agent workflow

An agent may summarize gaps and prepare a review queue. It must not fetch recorded URLs, infer protected traits, contact people, or approve employment actions. Keep the human approval step explicit.

Operating guide

Before each run, verify the licence, purpose, retention period, record count, absence of secrets and candidate data, and charge cap. After each run, compare requested/unique/duplicate/invalid counts, then attempted/successful/failed, then delivered/paid/free/withheld/unknown. Require current run ID and terminal KVS evidence.

Monitor changes to the public input schema, Dataset view, pricing event map, and SDK charging behavior. A priced default Dataset event invalidates the free-diagnostic promise and must fail closed. A nonzero initial result counter invalidates the current-run settlement proof and must fail closed.

Record preparation checklist

Use this checklist before creating an Input object:

1. Identify the system that produced the export and the organization that controls it.
2. Confirm that the intended analytical purpose is covered by ownership, licence, contract, or another reviewed basis.
3. Confirm that downstream Dataset delivery is covered, not merely access inside the original interface.
4. Remove applicant names, résumés, interview notes, scoring, demographic attributes, and private contact details.
5. Remove API keys, session tokens, signed download parameters, authentication cookies, and internal-only URLs.
6. Keep only fields that contribute to the approved review purpose.
7. Give the source a stable sourceName that distinguishes it from other feeds.
8. Write a concise sourceLicense statement that a reviewer can trace to the retained agreement.
9. Use one stable jobId per source record. Do not invent a new ID on every export.
10. Normalize timestamps to UTC before submission and retain the original system timestamp separately when required.
11. Set a finite run charge cap that covers the start event and the intended number of result rows.
12. Run a small sample first when the export format or licence scope has changed.

The Actor enforces shape and boundedness, but preparation remains the buyer’s responsibility. A perfectly valid JSON object can still be inappropriate to process if its rights, purpose, or data-minimization basis is missing.

Source identity and duplicate policy

A record identity is the pair sourceName + jobId. This matters when two licensed feeds use the same short ID. The first valid occurrence of a pair is kept; later occurrences in the same run are counted as duplicates. A matching jobId from a different sourceName is not silently merged because the sources may represent different contracts, versions, or records.

The stable Dataset identity is a SHA-256 digest of that pair. It supports deterministic joins and duplicate checks. It does not hide a low-entropy identifier from an attacker who already knows the likely source and ID, so it must not be treated as anonymization.

Duplicate handling is run-local. The Actor does not maintain a cross-run database and cannot tell whether the same record was delivered yesterday. If a caller needs cross-run idempotency, store stableId and the accepted run ID in its own controlled system, then decide whether a new paid run is necessary before starting it.

Timestamp interpretation

postedDate, validThrough, and sourceRetrievedAt are different facts:

• postedDate is the buyer-supplied publication timestamp and drives freshness;
• validThrough is an optional buyer-supplied closing or expiry timestamp;
• sourceRetrievedAt is when the buyer or licensed provider obtained the record;
• observedAt and legacy scraped_at are when this Actor processed it.

The Actor does not substitute one timestamp for another. It does not assume that a missing validThrough means the job is open. It does not assume that a fresh sourceRetrievedAt makes an old postedDate fresh. A timestamp after processing time creates an unknown freshness state instead of a silently negative age.

Confidence interpretation

Confidence is based on supplied evidence completeness, not source truth. A HIGH record has a closed valid shape, stable identity, rights attestation, and relatively few material gaps. It may still be false, withdrawn, duplicated outside this run, or unsuitable for the buyer’s purpose. A LOW record may be genuine but lack enough fields for a safe action.

Never translate confidence into applicant quality, employer quality, probability of hiring, or legal certainty. The object’s basis explains what was checked. Its gaps explain what was not established. Downstream systems should retain both.

Budget planning examples

At FREE-tier prices, one start plus one result is $0.008; one start plus ten results is $0.035; one start plus one hundred results is $0.305. These examples exclude compute usage and may not match a buyer’s discounted service tier. The current Store pricing page is authoritative.

If a cap covers the start but not another result, the Actor stops before that paid push and records remaining valid work as withheld. A withheld row was not delivered. A returned push with zero named-event movement is different: the Dataset write is known and settlement is free. A thrown push is different again: delivery itself is unknown.

Output acceptance checklist

An automated consumer should accept a clean run only when all of the following hold:

• OUTPUT.runId equals the platform run ID being processed;
• schemaVersion and kind are recognized;
• terminal.primaryKvsWrite is confirmed;
• terminal outcome and platform status agree;
• input.requestedCount = uniqueCount + duplicateCount + invalidCount;
• run.attemptedCount = successfulCount + failedCount;
• run.deliveredRowCount = paidRowCount + freeRowCount + unknownSettlementCount;
• run.withheldRowCount = uniqueCount - attemptedCount;
• confirmed named-event delta equals paidRowCount;
• confirmed Dataset writes equal delivered rows;
• unknown delivery and settlement counters are zero for automatic continuation;
• fatalError is null;
• every Dataset row has the same request digest as the current run;
• every business row keeps safeToAutomate:false and a human review action.

If any condition fails, route the run to manual review. Do not coerce a partial or failed receipt into success merely because the Dataset contains rows.

KVS write recovery

The Actor writes a primary terminal OUTPUT. If that write fails, it changes the terminal state to output_write_failed, marks the run fatal and partial, and makes one bounded recovery write. It never loops indefinitely. If the recovery write also fails, platform run status and logs remain the fallback evidence.

After a successful primary KVS write, the Actor requests normal exit. If exit throws, it writes an exit_failed recovery receipt and fails the run. This prevents a receipt claiming COMPLETE while the hosted execution is known to have failed its terminal transition.

Version and migration policy

Version 2.0 is a deliberate product replacement: source acquisition was removed, not hidden. Legacy source-scraper settings remain accepted to give existing callers an explicit free migration response. They cannot activate old network code. New integrations should use jobs and should treat version 2 Dataset and OUTPUT shapes as closed contracts.

Legacy Dataset field names remain additive compatibility aids. Their semantics are documented here. New code should prefer observedAt, sourceLicense, freshness, confidence, recommendedAction, and current-run OUTPUT rather than inferring meaning from scraped_at or found alone.

Replay policy

Pre-push failures may be safe to retry only after the cause is fixed and a new run is intentionally authorized. Any attempted push sets a boundary: do not retry blindly. Check the original run, Dataset, KVS, and platform charged-event counters first. A new run always incurs a new automatic start event.

Incident handling

Preserve run ID, build ID, input digest, Dataset ID, KVS ID, logs, charged-event counters, and receipt. Do not edit historical evidence. If delivery or settlement is unknown, stop automation and reconcile manually.

Retention and deletion

Set retention according to the approved purpose, not convenience. Delete Input, Dataset, and KVS records when they are no longer needed. If a downstream spreadsheet, warehouse, webhook target, or backup received a copy, deletion from Apify alone is not complete; follow the data through every recipient.

Document who can access the Actor and its storages. Restrict secrets through Apify secret input fields or external secret management, but do not submit a secret in this Actor’s job objects at all. The public schema contains no credential field because runtime never needs one.

Quality review sample

For a new feed, manually compare a bounded sample against the authorized source system. Confirm identity, title, company, location, timestamps, salary text, and validity. Record discrepancies as source-quality findings. Do not modify the Actor to guess missing facts. Correct upstream exports or leave explicit nulls and gaps.

Repeat that review after a source schema change, licence change, timestamp change, or unusual increase in invalid records. A green runtime receipt proves processing, not source fidelity.

Audit-trail minimum

For every production workflow, retain a compact audit record that names the approved purpose, source owner, contract or licence reference, export time, Actor build ID, run ID, request digest, Dataset ID, KVS ID, reviewer, review time, decision, and deletion deadline. Do not copy the complete job description into the audit record when a stable ID and controlled source reference are sufficient.

When a reviewer corrects a field, keep the supplied value and the correction as separate facts. Do not overwrite source evidence and then present the corrected value as if the provider supplied it. When a record is withdrawn or expires, record that downstream state in the buyer’s system; this Actor intentionally has no network authority to discover it later.

If an organization uses several licensed sources, maintain one source register. For each source, record permitted fields, territories, recipients, attribution text, update cadence, rate or volume limits, retention, sublicensing restrictions, and termination date. sourceLicense should point a reviewer to that register without exposing confidential contract text in a public Dataset.

The audit record should also state whether postedDate, validThrough, and salary were source facts or buyer-normalized fields before submission. The Actor preserves submitted values but cannot reconstruct transformations that happened upstream. Clear provenance prevents a downstream user from confusing a normalized operational field with an original source statement.

FAQ

Does this Actor scrape XING?

No. The slug is retained for backward compatibility, but version 0.2 makes no XING or other network request.

Can I submit XING records?

Only if you have permission that covers the intended processing and delivery. The Actor does not grant that permission and does not validate it.

Why keep the old slug?

Changing the public Actor identity would break existing integrations. The title, description, input, and output truthfully describe the replacement product while the slug remains stable.

What happens to old scraper settings?

They produce one free migration diagnostic and no network request. Move authorized records into jobs.

Are recorded URLs safe?

They are syntactically validated HTTPS strings and never fetched. They are not independently verified, and query strings may still contain sensitive tokens that should be removed.

Is priority a hiring recommendation?

No. It routes record review. It says nothing about a person, candidate, employer, job quality, or legal eligibility.

Can I automate outreach or applications?

No. Every row says safeToAutomate:false. Verify the vacancy and use a lawful, human-approved process.

Why is scraped_at present when nothing is scraped?

It is a legacy-compatible field and now equals processing time. Prefer observedAt in new integrations.

Does the Actor verify the licence?

No. It records the buyer’s statement and binds it to evidence. Legal and contractual review remains the buyer’s responsibility.

What does a SHA-256 digest prove?

It supports integrity comparison of normalized data. It does not prove truth, permission, ownership, freshness, or anonymity.

What does one result cost?

The current Store pricing table is authoritative. On the FREE service tier the result event is $0.003; the automatic start event is $0.005 and tier discounts may apply.

Will an invalid record be charged?

It is omitted and may contribute to one free diagnostic. It does not intentionally emit result-found.

Is the Dataset receipt enough?

No. Dataset billing is settlement-neutral. Read the current-run KVS OUTPUT for exact delivery and event movement.

Can I rerun after an error?

Only pre-push failures are potentially replay-safe. Any push attempt requires manual reconciliation before a new run.

Sources and rights

The replacement product uses no external source at runtime. The buyer supplies every record and must have rights for the intended processing and downstream delivery. Public accessibility, a sitemap, a robots rule, or an export button is not by itself a commercial redistribution licence.

The legacy implementation accessed XING website content. Version 0.2 removes that behavior completely. It does not keep a dormant fallback, hidden environment switch, diagnostic override, or indirect source call. The recorded job URL is evidence only and is never opened.

For employer-owned ATS exports, document the controller, purpose, fields, retention period, access list, and downstream recipients. For licensed feeds, retain the provider agreement, attribution requirements, field restrictions, expiry, and deletion duties. For any uncertainty, obtain legal review before submission.

The product is an evidence-normalization and review-routing tool. It is not a data broker, scraper, employment decision system, legal opinion, or authorization service.