Bewerber in ein eigenes System übernehmen

Überblick

Diese Seite beschreibt, wie ein eigenes Bewerbermanagement seinen Bewerberbestand aus talent.Flow aufbaut und laufend aktuell hält. Der Ablauf hat zwei Phasen: eine Erstbefüllung und danach ein Delta-Abgleich.

Kurzfassung: Einmalig alle aktiven Bewerber über GET /v3/candidates/export/candidates laden, danach im gewählten Takt die Änderungen über GET /v3/candidates/export/candidates/changes nachziehen. Nie den Gesamtbestand erneut ziehen.

Datenschutz: Bewerberdaten sind besonders schützenswerte personenbezogene Daten im Sinne der DSGVO. Übertragung, Speicherung und Löschung in Ihrem System müssen entsprechend abgesichert sein. Übernehmen Sie nur die Felder, die Sie fachlich benötigen.

Schritt 1: Erstbefüllung

curl -X GET https://api.talent360.io/v3/candidates/export/candidates \
  -H "Authorization: Bearer IHR_ACCESS_TOKEN" \
  -H "User-Agent: Mozilla/5.0 (Kundenname)" \
  -H "Accept: application/json"

Zweck	Endpunkt
Alle aktiven Bewerber	`GET /v3/candidates/export/candidates`
Bewerber auflisten (optional auf Zeitraum eingrenzbar)	`GET /v3/candidates`

Es gibt kein Paging. Weder skip noch take existieren. Bei großen Beständen grenzen Sie die Erstbefüllung über Zeitfenster ein — etwa monatsweise über startDate/endDate — statt einen einzelnen Aufruf über den Gesamtbestand abzusetzen.

Schritt 2: Delta-Abgleich

curl -X GET "https://api.talent360.io/v3/candidates/export/candidates/changes?startDate=2026-07-30&endDate=2026-07-31" \
  -H "Authorization: Bearer IHR_ACCESS_TOKEN" \
  -H "User-Agent: Mozilla/5.0 (Kundenname)" \
  -H "Accept: application/json"

Parameter	Bedeutung
`startDate`	Beginn des Zeitraums (`YYYY-MM-DD`)
`endDate`	Ende des Zeitraums (`YYYY-MM-DD`)
`officeId`	Auf eine Niederlassung einschränken
`processStatusId`	Auf einen Prozessstatus einschränken

Die Antwort ist bereits nach Änderungsart getrennt:

{
  "new":      [ … ],
  "modified": [ … ],
  "deleted":  [ … ]
}

Zweck	Endpunkt
Änderungen im Zeitraum	`GET /v3/candidates/export/candidates/changes`
Änderungen eines Tages	`GET /v3/candidates/export/candidates/changes/{date}`
Änderungen einer Stunde	`GET /v3/candidates/export/candidates/changes/{date}/{hour}`

Die deleted-Liste ist wichtiger, als sie aussieht. Die API hat keinen Endpunkt zum Löschen von Bewerbern — Löschungen erfahren Sie ausschließlich über diese Liste. Wer nur new und modified verarbeitet, sammelt mit der Zeit Karteileichen an, die in talent.Flow längst entfernt wurden. Das ist auch datenschutzrechtlich relevant.

Schritt 3: Details und Dokumente nachladen

Die Änderungsliste nennt die betroffenen Bewerber. Den vollständigen Datensatz holen Sie einzeln:

Zweck	Endpunkt
Volldatensatz eines Bewerbers	`GET /v3/candidates/export/candidates/{candidateId}`
Kurzprofil	`GET /v3/candidates/{id}`
Dokumentenliste eines Bewerbers	`GET /v3/candidates/export/candidates/{candidateId}/documents`
Einzelnes Dokument	`GET /v3/candidates/export/documents/{documentId}`
Geänderte Dokumente im Zeitraum	`GET /v3/candidates/export/documents/changes`
Geänderte Dokumente pro Tag	`GET /v3/candidates/export/documents/changes/{date}`
Geänderte Dokumente pro Stunde	`GET /v3/candidates/export/documents/changes/{date}/{hour}`

Dokumente haben einen eigenen Änderungsstrom. Ein Bewerber kann unverändert bleiben, während ein Dokument dazukommt — wer nur den Bewerberstrom abfragt, verpasst neue Lebensläufe und Zeugnisse.

Dubletten vermeiden

Vor dem Anlegen eines Bewerbers auf Ihrer Seite — oder bevor Sie einen in talent.Flow anlegen:

curl -X GET "https://api.talent360.io/v3/candidates/exists?email=max.mustermann@example.com" \
  -H "Authorization: Bearer IHR_ACCESS_TOKEN" \
  -H "User-Agent: Mozilla/5.0 (Kundenname)"

{
  "exists": true,
  "candidateId": 4711,
  "status": "Aktiv"
}

Endpunkt: GET /v3/candidates/exists

Die Antwort liefert neben exists auch die candidateId und den Status (Aktiv / Archiviert) — damit lässt sich ein bestehender Datensatz direkt weiterverwenden, statt einen zweiten anzulegen.

Bewerber tragen keine externe Id. Im Bewerberdatensatz gibt es kein Feld, in dem Ihr System seine eigene Id ablegen kann (bei Firmen gibt es dafür importExternalId). Führen Sie deshalb eine Zuordnungstabelle talent.Flow-candidateId ↔ eigene Id. Der Abgleich über Namen ist nicht zuverlässig, über E-Mail nur beim Ersteinstieg.

Historie

Wenn Sie den Verlauf statt des aktuellen Standes brauchen:

Zweck	Endpunkt
Statushistorie eines Bewerbers	`GET /v3/candidates/{id}/history/status`
Statushistorie zum Stichtag	`GET /v3/candidates/history/status/{date}`
Kontakthistorie eines Bewerbers	`GET /v3/candidates/{id}/history/contact`
Kontakthistorie zum Stichtag	`GET /v3/candidates/history/contact/{date}`

Empfehlungen

Erstbefüllung genau einmal. Danach ausschließlich Deltas — ein täglicher Vollabzug erzeugt Last ohne Erkenntnisgewinn.
Überlappende Zeitfenster wählen. Fragen Sie etwas mehr ab, als seit dem letzten Lauf vergangen ist, und deduplizieren Sie über die candidateId. Das überbrückt Laufzeitverschiebungen und kurze Ausfälle.
Den Zeitpunkt des letzten erfolgreichen Laufs persistieren — nicht die Systemzeit des aktuellen Laufs verwenden.
Dokumentenstrom separat abfragen.
deleted verarbeiten, sonst wächst ein Bestand an Datensätzen heran, die es nicht mehr geben darf.
Ein Access Token pro Tag (siehe Authentifizierung).

Checkliste

Erstbefüllung ist gelaufen und der Zeitstempel des letzten erfolgreichen Laufs wird gespeichert.
Der Delta-Lauf nutzt ein überlappendes Fenster und dedupliziert über candidateId.
new, modified und deleted werden verarbeitet.
Der Dokumentenstrom wird eigenständig abgefragt.
Eine Zuordnungstabelle für Bewerber-Ids existiert.
Löschung im eigenen System ist umgesetzt und datenschutzkonform dokumentiert.