For AI agents: the complete documentation index is at https://api-doc.talent360.io/llms.txt. Every page is also available as Markdown by appending index.md to its URL or by sending Accept: text/markdown.
Änderungen

Changelog

Diese Seite führt die Änderungen an der talent Flow API auf. Maßgeblich ist immer die API-Referenz — das Changelog nennt nur, was sich gegenüber der Vorversion geändert hat.

Version 3.4.0 - Release 14.09.2026

Diese Ausgabe fasst alle Änderungen seit 3.3.0 zusammen. Das Schema ist rein additiv: Alle bestehenden Schlüssel und Antwortformen bleiben erhalten. Fünf Verhaltensänderungen sind jedoch Breaking Changes für Clients, die sich auf das bisherige Verhalten verlassen — siehe die Box direkt darunter.

Breaking Changes in Version 3.4.0

  • 404 statt 204 bei unbekannter Id. GET /v3/customers/offices/{officeId}, GET /v3/customers/locations/{locationId} und GET /v3/customers/contacts/{contactId} antworten bei unbekannter oder gelöschter Id mit 404 und ErrorResponse. Bisher kam 204 ohne Inhalt. Clients, die 204 als „nicht gefunden" auswerten oder jeden Nicht-2xx-Status als Fehler behandeln, müssen umstellen.

  • Anfrage anlegen scheitert bei ungültigen Zuordnungen. POST /v3/customers/{customerId}/requests/… liefert 400 NotExisting, wenn eine Schicht- oder Führerschein-Id nicht aus dem jeweiligen Katalog stammt, und den jeweiligen Fehler, wenn ein Schlagwort oder eine Qualifikation nicht angelegt werden kann. Die Anfrage wird dann nicht angelegt. Bisher wurde sie mit 200 ohne die betroffenen Zuordnungen gespeichert; Arbeitsort-Ids (1246–1248) als Schicht gingen bisher durch und werden jetzt abgelehnt.

  • Rechtsform im Firmennamen wird abgetrennt. Endet name an POST /v3/customers oder PUT /v3/customers/{customerId} auf eine Rechtsform (z. B. „Musterfirma GmbH"), wird „Musterfirma" gespeichert und companyTypeId aus dem Suffix gesetzt — auch gegen einen mitgeschickten Wert. Der zurückgelesene Name ist damit kürzer als der gesendete.

  • Profil-URLs kommen als vollständige URL. linkedInUrl und xingUrl werden an allen Leseendpunkten mit Host geliefert (https://www.linkedin.com/…). Bisher lieferten Firmen- und Betriebsstättendetails nur den Pfad. Clients, die den Host selbst voranstellen, erzeugen jetzt doppelte URLs.

  • Straße mit Hausnummer wird zerlegt. Wird street mit Hausnummer und ohne streetNumber gesendet („Musterstraße 5a"), speichert die API street = „Musterstraße" und streetNumber = „5a". Beim Zurücklesen stehen die Werte getrennt, nicht mehr wie gesendet.

Neue Endpunkte

Firmenbereich ändern und löschen — bisher ließen sich Einsatzorte nicht ändern und im Firmenbereich nichts löschen:

Endpunkt Zweck
PUT /v3/customers/{customerId}/offices/{officeId}/locations/{locationId} Neu in V 3.4.0: Einsatzort ändern. Teil-Update; das Umhängen auf eine andere Betriebsstätte ist nicht möglich
PUT /v3/customers/{customerId}/requests/{requestId} Neu in V 3.4.0: Betriebsstätte, Einsatzort und Ansprechpartner einer Anfrage ändern. Geprüft wird immer die resultierende Kombination
DELETE /v3/customers/{customerId}/offices/{officeId} Neu in V 3.4.0: Betriebsstätte löschen (Soft-Delete). Einsatzorte, Kontaktzuordnungen und Anfragen bleiben bestehen
DELETE /v3/customers/{customerId}/offices/{officeId}/locations/{locationId} Neu in V 3.4.0: Einsatzort löschen (Soft-Delete)
DELETE /v3/customers/{customerId}/contacts/{contactId} Neu in V 3.4.0: Ansprechpartner löschen (Soft-Delete)
DELETE /v3/customers/{customerId}/requests/{requestId} Neu in V 3.4.0: Anfrage löschen (Soft-Delete); GET /v3/requests/{id} liefert anschließend 404
DELETE /v3/candidates/{candidateId}/keywords/{keywordId} Neu in V 3.4.0: Schlagwort eines Bewerbers entfernen (Soft-Delete). keywordId ist die Schlagwort-Id, nicht die Id der Zuordnung

Gelöscht wird in allen Fällen als Soft-Delete, genau wie in talent.Flow. Ein Datensatz, der nicht zur angegebenen Firma gehört oder bereits gelöscht ist, ergibt 404.

Neue Stammdatenlisten:

Endpunkt Inhalt
GET /v3/customers/corporations Neu in V 3.4.0: Konzerne des Accounts, zulässige Werte für corporationId
GET /v3/masterdata/contractdurations Neu in V 3.4.0: Vertragslaufzeiten (contractDurationId)
GET /v3/masterdata/workplaces Neu in V 3.4.0: Arbeitsorte (workPlaceId)
GET /v3/masterdata/shifts Neu in V 3.4.0: Schichten (shiftIds)
GET /v3/masterdata/currencies Neu in V 3.4.0: Währungen mit ISO-Code und Symbol (wageCurrencyId, serviceContractWageCurrencyId)

Neue und erweiterte Felder

Bestehende Aufrufe bleiben gültig — die neuen Felder sind optional:

Endpunkt Neu in V 3.4.0
POST /v3/customers, PUT /v3/customers/{customerId} corporationId ordnet einen bestehenden Konzern zu
GET /v3/customers/{id} corporationId und corporation; notes und ranking sind jetzt lesbar
GET /v3/customers/locations/{locationId}, GET /v3/customers/offices/{officeId} importExternalId und importedAtUtc an Einsatzorten (bisher immer null)
GET /v3/requests/{id} labourLeasingDurationUnit liefert den Anzeigetext (bisher immer null)
POST /v3/candidates, PUT /v3/candidates/{candidateId} contact.phoneNumber und contact.mobileNumber werden beide gespeichert (bisher ging phoneNumber verloren, wenn beide befüllt waren); der Bewerberexport liefert beide Nummern
POST /v3/customers/{customerId}/requests/servicecontract Die Vertrags- und Konditionsfelder (contractDurationId, workPlaceId, Befristung, Arbeitszeitmodell, Sprachen, Dienstwagenbudget, Zusatzleistungen) werden gespeichert und validiert (bisher still verworfen)
PUT Firma, Betriebsstätte, Kontakt, Einsatzort createdAtUtc wird auch beim Ändern übernommen, für Importe, die das Erstelldatum des Quellsystems nachtragen
PUT /v3/customers/{customerId}/offices/{officeId} addressLine1 und addressLine2 werden auch auf oberster Ebene akzeptiert

Geändertes Verhalten

Die fünf Breaking Changes aus der Box oben sind hier der Vollständigkeit halber mit aufgeführt.

  • Neu in V 3.4.0: GET /v3/customers/offices/{officeId}, GET /v3/customers/locations/{locationId} und GET /v3/customers/contacts/{contactId} liefern bei unbekannter oder gelöschter Id 404 mit ErrorResponse. Bisher 204 ohne Inhalt. (Breaking)

  • Neu in V 3.4.0: Beim Anlegen einer Anfrage (POST /v3/customers/{customerId}/requests/…) bricht ein Fehler bei Schichten, Führerscheinen, Qualifikationen oder Schlagwörtern das Anlegen ab. Unbekannte oder gruppenfremde Schicht-/Führerschein-Ids liefern 400 NotExisting auf ShiftIds bzw. DriversLicenseIds. Bisher wurde die Anfrage mit 200 ohne die betroffenen Zuordnungen gespeichert, eine unbekannte Id lief in einen 500. (Breaking)

  • Neu in V 3.4.0: responsibility wird an PUT Firma, Betriebsstätte und Kontakt ausgewertet. Bisher wurde das Objekt still verworfen.

  • Neu in V 3.4.0: assignedOfficeIds: null am PUT Kontakt wird ignoriert und antwortet mit 204 (bisher 500). [] entfernt weiterhin alle Zuordnungen.

  • Neu in V 3.4.0: PUT /v3/customers/{customerId}/contractstatus antwortet mit 404 NotAssignedToRequest, wenn der Bewerber der Anfrage nicht zugeordnet ist (bisher 500), und mit 400 PlacementTypeNotSupported, wenn die Anfrage keine Arbeitnehmerüberlassung oder Personalvermittlung ist (bisher 400 ohne Begründung).

  • Neu in V 3.4.0: contacts[].assignedOfficeIds an GET /v3/customers/offices/{officeId} ist nie mehr null und enthält alle Zuordnungen des Ansprechpartners.

  • Neu in V 3.4.0: linkedInUrl und xingUrl werden an allen Leseendpunkten als vollständige URL mit Host geliefert. POST/PUT Kontakt akzeptieren die vollständige URL, einen Host ohne Schema oder nur den Profilpfad; ein fremder Host liefert 400 InvalidUrl. (Breaking)

  • Neu in V 3.4.0: Endet name an POST/PUT Firma auf eine Rechtsform (z. B. „GmbH"), wird sie abgetrennt und companyTypeId daraus gesetzt. Der gespeicherte Name wird dadurch gekürzt. (Breaking)

  • Neu in V 3.4.0: Enthält street Straße und Hausnummer und fehlt streetNumber, zerlegt die API den Wert selbst. (Breaking)

  • Neu in V 3.4.0: Ein Länderwechsel ohne federalStateId leert das gespeicherte Bundesland, statt den Aufruf mit 400 abzulehnen (Firma, Betriebsstätte, Einsatzort).

  • Neu in V 3.4.0: Schlägt die Geokodierung einer Adresse fehl, bleiben vorhandene Koordinaten erhalten.

  • Neu in V 3.4.0: POST /v3/candidates/{id}/apply mit jobAdId scheitert nicht mehr, wenn der Berufstitel der Stellenanzeige noch nicht als Schlagwort existiert.

  • Neu in V 3.4.0: POST /v3/candidates/{id}/keywords, …/qualifications und …/professions liefern in jedem Fall die Stammsatz-Id, auch wenn die Zuordnung bereits bestand oder reaktiviert wurde.

  • Neu in V 3.4.0: GET /v3/requests/{id} liefert keywords und qualifications unmittelbar nach dem Anlegen, auch für neue Begriffe.

  • Neu in V 3.4.0: GET /v3/customers/{id} und POST /v3/customers ohne Token antworten mit 401 (bisher 500).

Angekündigt

Telefonnummern an POST /v3/candidates und PUT /v3/candidates/{candidateId} werden künftig gegen den internationalen Rufnummernkatalog geprüft. Derzeit wird nichts abgelehnt; ungültige Werte werden gespeichert und nur protokolliert. Eine Ablehnung mit 400 wird vorher angekündigt.

Migrationshinweise

  • Wer beim Lesen von Betriebsstätte, Einsatzort oder Kontakt auf 204 als „nicht gefunden" prüft, muss auf 404 umstellen.

  • Wer linkedInUrl/xingUrl selbst mit Host präfixiert, entfernt das: Die API liefert jetzt die vollständige URL.

  • Wer den Firmennamen bewusst mit Rechtsform führt, muss damit rechnen, dass er gekürzt wird; companyTypeId getrennt liefern und den Namen ohne Rechtsform senden.

  • Straße und Hausnummer getrennt in street und streetNumber senden; wer streetNumber mitschickt, schaltet die Zerlegung ab.

  • shiftIds und driversLicenseIds ausschließlich mit Werten aus /v3/masterdata/shifts bzw. /v3/masterdata/driverslicenses befüllen; Arbeitsort-Ids als Schicht werden ab jetzt abgelehnt.

  • Beim Anlegen einer Anfrage Fehlerantworten auswerten: Ein 400 bedeutet jetzt, dass die Anfrage nicht angelegt wurde.

  • Die neuen Felder und Endpunkte erfordern keine Anpassung; alle neuen Request-Felder sind optional.

Version 3.3.0

Diese Ausgabe fasst alle Änderungen seit 3.0.0 zusammen.

Neue Endpunkte

Bewerber ändern und löschen — bis dahin ließen sich Bewerberstammdaten nur anlegen, nicht mehr ändern:

Endpunkt Zweck
PUT /v3/candidates/{candidateId} Bewerberstammdaten ändern. Teil-Update: nur die übermittelten Felder werden geändert
PUT /v3/candidates/{candidateId}/languages/{languageId} Sprache ändern
DELETE /v3/candidates/{candidateId}/driverslicences/{driversLicenseId} Führerschein löschen
DELETE /v3/candidates/{candidateId}/languages/{languageId} Sprache löschen
DELETE /v3/candidates/{id}/professions/{professionId} Beruf löschen
DELETE /v3/candidates/{id}/qualifications/{qualificationId} Qualifikation löschen

Dies sind die einzigen Löschendpunkte der API. Für den Bewerber selbst, seine Kontaktwege, den Werdegang, Keywords und Dokumente sowie für den gesamten Firmenbereich gibt es weiterhin keinen — dort führt der Weg über den Statuswechsel.

Neue Stammdatenlisten — acht zusätzliche Wertelisten:

Endpunkt Inhalt
GET /v3/masterdata/nationalities Nationalitäten
GET /v3/masterdata/maritalstatus Familienstände
GET /v3/masterdata/employmenttypes Arbeitszeitmodelle
GET /v3/masterdata/disabilitytypes Arten der Behinderung
GET /v3/masterdata/mobilitytypes Mobilitätsarten
GET /v3/masterdata/bonustypes Bonusarten
GET /v3/masterdata/periods Zeiteinheiten
GET /v3/masterdata/salutations Anreden

Erweiterte Endpunkte

Bei diesen Endpunkten wurde der Request-Body erweitert. Bestehende Aufrufe bleiben gültig — die neuen Felder sind optional:

Endpunkt
POST /v3/candidates Stammdaten anlegen
PUT /v3/candidates/{candidateId}/workcontract Arbeitsvertrag
POST /v3/customers Firma anlegen
PUT /v3/customers/{customerId} Firma ändern
POST /v3/customers/{customerId}/contacts Kontakt anlegen
PUT /v3/customers/{customerId}/contacts/{contactId} Kontakt ändern
POST /v3/customers/{customerId}/offices Betriebsstätte anlegen
PUT /v3/customers/{customerId}/offices/{officeId} Betriebsstätte ändern

Ebenfalls erweitert wurden die Antworten von GET /v3/candidates und GET /v3/candidates/export/candidates/{candidateId}.

Migrationshinweise

  • Wer Bewerberstammdaten bisher nicht ändern konnte, kann das jetzt über PUT /v3/candidates/{candidateId} — und muss dabei nur die geänderten Felder senden.

  • Die erweiterten Request-Bodies erfordern keine Anpassung; die neuen Felder sind optional.