ОUЯUKΛ / Changelog

Was sich geändert hat.

Alle öffentlichen Versionen von OURUKA — von der ersten API bis heute. Interne Änderungen werden nicht aufgeführt.

Version 2.3.1

Patch 2026-04-26
Changed
  • POST /v2/keyify erfordert jetzt einen X-API-KEY Header — einheitlich mit allen anderen Endpunkten

Version 2.2.0

Minor Release 2026-04-26
Added
  • /v2/uid/numeric und /v2/uid/alpha erfordern jetzt einen X-API-KEY Header
  • POST /v2/schemas: Die Antwort enthält jetzt preview — eine Vorschau der ersten ID ohne Zähler-Inkrement
  • GET /v2/schemas: Jedes Schema enthält jetzt preview, last_generated (zuletzt generierte ID) und last_generated_at

Version 2.1.0

Minor Release 2026-04-25
Added
  • Mapping Tables — zentrale Lookup-Tabellen für attributbasierte ID-Generierung
  • Neuer Platzhalter {MAP:tabellenname} im Schema-Pattern — Wert wird zur Laufzeit aus der Tabelle aufgelöst
  • Vollständige CRUD-Endpunkte für Mapping-Tabellen: anlegen, auflisten, abrufen, löschen
  • Paketabhängige Limits für Tabellen-Anzahl und Einträge pro Tabelle
  • GET /v2/me zeigt jetzt auch Mapping-Limits und aktuelle Tabellen-Anzahl

Version 2.0.0

Major Release 2026-04-25
Added
  • Paket-System: vier Stufen mit definierten Limits — Discovery (Trial, 2 Schemas, 2.000 IDs/Monat), Orbit (5 Schemas, 10.000 IDs/Monat), Galaxy (15 Schemas, 50.000 IDs/Monat), Universe (30 Schemas, 150.000 IDs/Monat)
  • Monatlicher ID-Verbrauch wird automatisch getrackt; bei Limitüberschreitung wird auf das nächste Paket hingewiesen
  • GET /v2/me gibt jetzt Paket-Limits und aktuellen Verbrauch zurück

Version 1.5.0

Minor Release 2026-04-24
Added
  • Rate-Limiting für öffentliche Endpunkte: max. 60 Anfragen pro Minute pro IP-Adresse

Version 1.4.0

Minor Release 2026-04-24
Added
  • Neuer Schema-Typ hash für deterministisches Content-Fingerprinting
  • Gleiche Eingabe → immer gleicher Hash (SHA-256, Länge wählbar: 16, 32, 40 oder 64 Zeichen)
  • Typischer Anwendungsfall: Dublikatserkennung beim Lieferanten- oder Datensatz-Onboarding
  • Hash-IDs werden wie alle anderen IDs in der History gespeichert — Duplikate sofort erkennbar

Version 1.3.0

Minor Release 2026-04-23
Added
  • {COUNTER:N:interval} — Counter mit automatischem Reset pro Periode. Intervalle: daily, monthly, quarterly, yearly. Beispiel: {COUNTER:4:yearly} → startet jedes Jahr neu bei 0001
  • Schema-Löschung gibt jetzt eine Zusammenfassung zurück: Anzahl gelöschter History-Einträge und Counter
Changed
  • Interne Datenbankstruktur optimiert für höhere History-Stabilität
  • Aufräumlogik im Hintergrund verbessert

Version 1.2.2

Patch 2026-04-20
Added
  • GET /v2/changelog — Versionshistorie des Service abrufbar als JSON
Changed
  • Schemas sind nach dem Anlegen unveränderlich. Zum Ändern: Schema löschen und neu anlegen
  • Sicherheitsverbesserungen im Authentifizierungsbereich
Fixed
  • DELETE /v2/schemas/{name} räumt jetzt vollständig auf — History-Einträge werden mitgelöscht

Version 1.2.1

Patch 2026-03-19
Added
  • UIDs: Erlaubte Längen auf 256 und 512 Zeichen erweitert
  • Swagger UI deutlich ausgebaut: Endpunkt-Beschreibungen, Platzhalter-Erklärungen, Beispiele und Anwendungsfälle ergänzt

Version 1.2.0

Minor Release 2026-03-12
Added
  • GET /health gibt jetzt die aktuelle Service-Version zurück
  • Hintergrund-Worker für automatische Bereinigung abgelaufener Daten (Intervall: 12 Stunden)

Version 1.1.0

Minor Release 2026-02-25
Added
  • POST /v2/uid/numeric — kryptografisch zufällige numerische ID (Längen: 16, 32, 64, 128 Zeichen)
  • POST /v2/uid/alpha — kryptografisch zufällige alphanumerische ID (a–z, A–Z, 0–9)
  • POST /v2/keyify — UTF-8-String in systemsicheren ASCII-Schlüssel umwandeln (Umlaut-Transliteration)

Version 1.0.0

Major Release 2026-02-25
Added
  • REST-API zur Generierung eindeutiger, regelbasierter IDs
  • Schema-Patterns mit Platzhaltern: {DATE:YYYY}, {DATE:MM}, {DATE:DD}, {COUNTER:N}, {VAR1}{VAR4}
  • ID-History pro Schema (abrufbar mit Zeitstempel)
  • Multi-Tenancy: jeder API-Key erhält einen isolierten Bereich mit eigenen Schemas und Countern
  • GET /health — Systemstatus mit PostgreSQL- und Redis-Check