2.8.0 · 2026-07-26
Changed
- Echte Client-IP-Ermittlung:
X-Forwarded-For (bzw. X-Real-IP) wird ausgewertet. Die History-source_ip zeigt dadurch die tatsächliche Client-IP statt der Reverse-Proxy-IP, und das Rate-Limiting öffentlicher Endpunkte wirkt pro echtem Client statt global pro Proxy.
- Voraussetzung: Der vorgelagerte Reverse-Proxy muss
X-Forwarded-For korrekt setzen. Ohne Proxy-Header bleibt das Verhalten unverändert (Fallback auf die direkte Verbindungs-IP).
2.5.0 · 2026-07-23
Added
POST /v2/me/rotate-key – eigenen API-Key rotieren (Self-Service, authentifiziert mit dem aktuellen Key). Der neue Key wird einmalig zurückgegeben, der bisherige wird sofort ungültig.
POST /v2/tenants/{id}/rotate-key – Admin-Notfallfunktion (Master-Key), um den API-Key eines Tenants neu zu erzeugen, falls dieser seinen Key verloren hat.
GET /v2/history unterstützt jetzt Paginierung über ?offset=N (z.B. ?limit=50&offset=50 für die zweite Seite).
- Changelog-Einträge können als
[intern] markiert werden; das Feld internal in der /v2/changelog-Antwort erlaubt Clients (z.B. der App), rein technische Versionen auszublenden.
2.3.1 · 2026-04-26
Changed
POST /v2/keyify erfordert jetzt einen X-API-KEY Header (einheitlich mit allen anderen Endpunkten)
- Swagger-Doku von
/v2/keyify aktualisiert: @Security ApiKeyAuth, 401-Response ergänzt
2.2.0 · 2026-04-26
Added
- UID-Endpunkte
/v2/uid/numeric und /v2/uid/alpha erfordern jetzt einen X-API-KEY Header
- Generierte UIDs werden maskiert in der History gespeichert (nur letzte 5 Zeichen sichtbar, z.B.
***********g7h8i)
- UIDs zählen zum monatlichen ID-Kontingent und werden bei Trial-/Limit-Überschreitung abgelehnt
POST /v2/schemas: Antwort enthält jetzt preview – Vorschau der ersten ID ohne Counter-Inkrement
GET /v2/schemas: Jedes Schema enthält jetzt preview, last_generated (zuletzt generierte ID) und last_generated_at (Zeitstempel der letzten Generierung)
2.1.0 · 2026-04-25
Added
- Mapping-Tabellen: zentrale Lookup-Tabellen für attributbasierte ID-Generierung
- Neuer Platzhalter
{MAP:tabellenname} im Schema-Pattern – Wert wird zur Laufzeit aus der Tabelle aufgelöst
POST /v2/mappings/{table} – Eintrag anlegen oder aktualisieren (weiss → 101)
GET /v2/mappings – alle eigenen Mapping-Tabellen auflisten
GET /v2/mappings/{table} – alle Einträge einer Tabelle abrufen
DELETE /v2/mappings/{table}/{entry} – einzelnen Eintrag löschen
DELETE /v2/mappings/{table} – gesamte Tabelle 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
2.0.0 · 2026-04-25
Added
- Paket-System: vier Stufen mit definierten Limits (Schemas und IDs pro Monat)
- Discovery – 2 Schemas, 250 IDs/Monat (14-tägiger Testzeitraum)
- Orbit – 5 Schemas, 2.000 IDs/Monat
- Galaxy – 10 Schemas, 5.000 IDs/Monat
- Universe – 20 Schemas, 10.000 IDs/Monat
- Monatlicher ID-Verbrauch wird automatisch getrackt und bei Limitüberschreitung mit Hinweis auf das nächste Paket quittiert
GET /v2/me gibt jetzt Paket-Limits und aktuellen Verbrauch zurück
PATCH /v2/tenants/{id} – Paket, Status oder Bonus-Kontingent eines Mandanten ändern (nur Master-Key)
Changed
- Neue Discovery-Mandanten erhalten automatisch einen 14-tägigen Testzeitraum
- Bestehende Mandanten wurden auf Galaxy migriert
1.5.0 · 2026-04-24
Added
DELETE /v2/tenants/{id} – vollständige Löschung eines Mandanten inkl. aller Schemas, IDs und Verlaufsdaten (nur für das Ouruka-Backend, erfordert Master-Key)
- Rate-Limiting für stateless Endpunkte:
/v2/uid/numeric, /v2/uid/alpha, /v2/keyify, /v2/changelog – max. 60 Anfragen pro Minute pro IP-Adresse
1.4.0 · 2026-04-24
Added
- Neuer Schema-Typ
hash für deterministisches Content-Fingerprinting
- Gleiche Eingabe → immer gleicher Hash-Wert (SHA-256, Länge wählbar: 16, 32, 40 oder 64 Zeichen)
- Typischer Anwendungsfall: Lieferanten- oder Datensatz-Deduplizierung ohne eigenen Hash-Service
- Hash-IDs werden wie alle anderen IDs in der History gespeichert – Duplikate sofort erkennbar
1.3.0 · 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
DELETE /v2/schemas/{name} gibt jetzt eine Zusammenfassung zurück: wie viele History-Einträge und Counter gelöscht wurden
Changed
- History-Stabilität verbessert: interne Datenbankstruktur optimiert
- History-Bereinigung: robustere Aufräumlogik im Hintergrund
1.2.2 · 2026-04-20
Added
GET /v2/changelog – Versionshistorie des Service abrufbar als JSON
Changed
POST /v2/schemas: Ein Schema kann nach dem Anlegen nicht mehr verändert werden. 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)
1.2.1 · 2026-03-19
Added
uid: Erlaubte Längen auf 256 und 512 Zeichen erweitert
- Swagger: Tag-Reihenfolge festgelegt (system → tenants → schemas → generate → uid → keyify → history)
- Swagger: Beschreibungen aller Endpunkte überarbeitet – Platzhalter-Erklärungen, Beispiele und Anwendungsfälle ergänzt
- Swagger: Host und Scheme werden zur Laufzeit dynamisch über
SWAGGER_HOST gesetzt (Produktion: https://ouruka.com)
Changed
- Swagger-Beispiele konsistent auf das Bestellungs-Szenario ausgerichtet (
ORD-202503-RED-XL-00001)
1.2.0 · 2026-03-12
Added
- Versionierung über Build-Zeit
ldflags (-X main.version=1.2.0)
- Automatischer Cleanup-Worker (Intervall: 12h) für abgelaufene Daten
GET /health gibt jetzt "version" zurück
Changed
- Interne Architektur:
Server-Struct mit Context-awaremen Background-Worker
1.1.0 · 2026-02-25
Added
POST /v2/uid/numeric – Kryptografisch zufällige numerische ID (Längen: 16, 32, 64, 128)
POST /v2/uid/alpha – Kryptografisch zufällige alphanumerische ID (Längen: 16, 32, 64, 128)
POST /v2/keyify – UTF-8-String in systemsicheren ASCII-Schlüssel umwandeln (Umlaut-Transliteration)
1.0.0 · 2026-02-25
Added
GET /health – Systemstatus mit PostgreSQL- und Redis-Check
POST /v2/tenants – Tenant anlegen (interner Endpunkt, Master-Key geschützt)
GET /v2/me – Eigene Tenant-Stammdaten abrufen
POST /v2/schemas – ID-Schema anlegen oder aktualisieren
GET /v2/schemas – Alle Schemas des Tenants auflisten
DELETE /v2/schemas/{name} – Schema löschen und Counter zurücksetzen
POST /v2/generate/{name} – ID anhand eines Schemas generieren (mit VAR1–VAR4 Unterstützung)
GET /v2/history – Verlauf der generierten IDs (limit: 1–200)
- Multi-Tenancy über
X-API-KEY Header
- Redis-Counter mit AOF-Persistenz
- PostgreSQL für Tenant- und Schema-Verwaltung sowie History