Datenmodell

Bewerbungen

Verbindet ein Talent mit einer Stelle. Trägt Stage (Eingang -> Sichtung -> Screening -> Interview -> Angebot -> Eingestellt | Abgelehnt | Talent-Pool), KI-Fit-Score, Quelle, Anschreiben-URL, Lebenslauf-URL und Position innerhalb der Pipeline-Spalte (Kanban-Reihenfolge).

Modellname: application

Endpunkte: 5

Max. Seitengröße: 500

Felder

Validierungsregeln pro Feld. Werte, die diese Bedingungen verletzen, werden mit 400 abgewiesen, bevor sie die Datenbank erreichen.

Feld	Typ	Regeln
tags	`tags`	-
stage	`enum`	enum`new \| review \| screening \| interview \| offer \| hired \| rejected \| talent_pool`
cv_url	`url`	max. Länge`2048`
job_id	`string`	max. Länge`64`ref →`job`
answers	`list`	-
position	`number`	-
fit_flags	`tags`	-
fit_score	`number`	-
source_id	`string`	max. Länge`64`ref →`source`
applied_at	`string`	max. Länge`32`
cv_blob_id	`string`	max. Länge`64`
candidate_id	`string`	max. Länge`64`ref →`candidate`
cover_letter	`string`	max. Länge`16000`
source_label	`string`	max. Länge`200`
fit_reasoning	`string`	max. Länge`4000`
last_stage_at	`string`	max. Länge`32`
rejected_note	`string`	max. Länge`2000`
previous_stage	`string`	max. Länge`32`
fit_computed_at	`string`	max. Länge`32`
rejected_reason	`enum`	enum`not_qualified \| salary_mismatch \| location_mismatch \| culture_mismatch \| withdrew \| ghosted \| filled_internally \| duplicate \| other`

Mutabilität

Welche Felder darfst du senden, und wann? Felder ohne Markierung werden vom Server vergeben - das Senden ist kein Fehler, sie werden stillschweigend ignoriert.

Anlegbar - im POST-Body lesbar.Änderbar - im PATCH-Body lesbar.Server-verwaltet - vom Body ignoriert.

Feld	Typ	Anlegbar	Änderbar
tags	tags
stage	enum
cv_url	url
job_id	string
answers	list
position	number
fit_flags	tags
fit_score	number
source_id	string
applied_at	string
cv_blob_id	string
candidate_id	string
cover_letter	string
source_label	string
fit_reasoning	string
last_stage_at	string
rejected_note	string
previous_stage	string
fit_computed_at	string
rejected_reason	enum

Felder mit Anlegbar, aber ohne Änderbar, sind nach dem Erstellen unveränderlich. Server-verwaltete Felder umfassen id, Zeitstempel, Eigentümerschaft und Status.

Filter & Sortierung

Auf Listen-Endpunkten kombinierbar. Wiederholte Filter-Keys werden zu IN-Bedingungen, ein - vor einem Sort-Key kehrt die Richtung um. Beispiel: ?status=open&status=blocked&sort=-created_at.

Filter-Keys

job_iddata__job_id

candidate_iddata__candidate_id

stagedata__stage

source_iddata__source_id

rejected_reasondata__rejected_reason

is_archiveddata__is_archived

status

is_archivedis_archived

owned_byowned_by

created_bycreated_by

Sortier-Keys

created_atcreated_at

updated_atupdated_at

applied_atdata__applied_at

fit_scoredata__fit_score

positiondata__position

last_stage_atdata__last_stage_at

Standard: position

Endpunkte

Jeder Endpunkt unten zeigt seine HTTP-Methode, den Pfad und den dafür benötigten PAT-Scope. Code-Beispiele decken curl, JavaScript, TypeScript, Python, Rust, Java und WebSocket ab.

GET/xapi2/data/applicationapplication:list

Objekte auflisten

Liefert eine paginierte Liste sichtbarer Objekte. Standard-Seitengröße 20; mit ?limit= änderbar (typabhängig begrenzt). ?after=<id> für Keyset-Paginierung bei nach created_at sortierten Listen, ?offset= für Offset-Paginierung.

curl -H "Authorization: Bearer pat_…" \
     "https://www.ki-bewerber-management.de/xapi2/data/application?limit=20"

GET/xapi2/data/application/{id}application:read

Einzelnes Objekt lesen

Liefert das Objekt anhand der ID. 404, falls es nicht existiert oder du keinen Lese-Zugriff hast (beide Fälle sind bewusst zusammengelegt).

curl -H "Authorization: Bearer pat_…" \
     https://www.ki-bewerber-management.de/xapi2/data/application/OBJECT_ID

POST/xapi2/data/applicationapplication:create

Erstellen

Erstellt ein neues Objekt. Der Body ist ein flaches JSON-Dict mit Feldwerten. Server-seitige Felder (id, Zeitstempel, Ownership) werden automatisch gefüllt; nur die unten als anlegbar gelisteten Felder werden aus dem Body übernommen.

curl -H "Authorization: Bearer pat_…" \
     -H "Content-Type: application/json" \
     -X POST https://www.ki-bewerber-management.de/xapi2/data/application \
     -d '{"name": "…"}'

PATCH/xapi2/data/application/{id}application:update

Aktualisieren

Teilweise Aktualisierung. Nur Felder im Body werden verändert; alles andere bleibt erhalten. Gleiche Erlaubnisliste wie bei Create, abzüglich der nach dem Anlegen unveränderlichen Felder.

curl -H "Authorization: Bearer pat_…" \
     -H "Content-Type: application/json" \
     -X PATCH https://www.ki-bewerber-management.de/xapi2/data/application/OBJECT_ID \
     -d '{"name": "…"}'

DELETE/xapi2/data/application/{id}application:delete

Löschen

Entfernt das Objekt. Es verschwindet sofort aus allen Standard-Listen und wird von read / list nicht mehr zurückgegeben.

curl -H "Authorization: Bearer pat_…" \
     -X DELETE https://www.ki-bewerber-management.de/xapi2/data/application/OBJECT_ID

In der CLI

Dieselben Endpunkte sind auch über die KI BMS CLI verfügbar. Für Skripte, CI und Bulk-Imports ist sie meist die schnellere Wahl.

atscli application list --limit 5
atscli application get <id>
atscli application create --job-id "Hello"
atscli application upsert --unique job_id --csv items.csv
atscli application schema   # Felder & Limits

Volle Befehlsreferenz, Profile, CSV-Import, Auto-Retry, NDJSON-Streaming → /docs/cli