Sessions

Eine Session bündelt das verschlüsselte Pseudonym-Mapping in Redis. Anonymize und Deanonymize laufen immer gegen eine Session; ohne gültige session_id kein Round-Trip.

POST /v1/cortina/session

Erstellt eine neue aktive Session und initialisiert das leere verschlüsselte Redis-Envelope.

Auth: Bearer Token erforderlich.

Request-Body

Feld	Typ	Required	Default	Beschreibung
ttl_seconds	integer	nein	3600	Session-TTL in Sekunden. Bounds: [60, 86400].

Beispiel-Request

curl -sS -X POST https://api.tup-ai.de/v1/cortina/session \
  -H "Authorization: Bearer $TUP_ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"ttl_seconds": 600}'

Response (201 Created)

Feld	Typ	Beschreibung
session_id	string (UUID)	Identifier für die nächsten Anonymize-/Deanonymize-Calls.
expires_at	string (ISO8601)	UTC-Timestamp, ab dem die Session expired ist.
status	enum	"active" | "expired" | "destroyed" — beim Create immer "active".

{
  "session_id": "018f4a2c-3d7e-7b4a-8c1e-2f9b3d4e5a6f",
  "expires_at": "2026-05-06T20:00:00Z",
  "status": "active"
}

Error-Codes

HTTP	code	Wann
401	unauthorized	Auth-Header fehlt oder Key ungültig.
422	validation_error	ttl_seconds außerhalb [60, 86400].
429	rate_limit_exceeded	Per-Key Rate-Limit erreicht.

DELETE /v1/cortina/session/{session_id}

Zerstört eine Session und wiped das Redis-Mapping sofort. Idempotent — ein Delete auf eine bereits zerstörte oder expirede Session gibt ebenfalls 204.

Auth: Bearer Token erforderlich.

Path-Parameter

Name	Typ	Required	Beschreibung
session_id	string (UUID)	ja	Die zu zerstörende Session-ID.

Beispiel-Request

curl -sS -X DELETE https://api.tup-ai.de/v1/cortina/session/018f4a2c-3d7e-7b4a-8c1e-2f9b3d4e5a6f \
  -H "Authorization: Bearer $TUP_ANON_KEY"

Response (204 No Content)

Kein Body.

Error-Codes

HTTP	code	Wann
401	unauthorized	Auth-Header fehlt oder Key ungültig.
422	validation_error	session_id ist keine valide UUID.
429	rate_limit_exceeded	Per-Key Rate-Limit erreicht.

Hinweis: Eine valide UUID, die nie existiert hat, gibt ebenfalls 204 — der Endpoint ist explizit fault-tolerant gegen Doppel-Deletes und “clean-up nach unsicherem State”-Patterns.