Zum Inhalt springen

Open Beta – hilf uns beim Testen! Alle Inserate sind nur Beispiele.

WOHNO

API-Changelog

Chronologische, additive Historie der WOHNO-REST-API: jede neue Ressource, jeder Endpoint und Scope, Welle für Welle.

Dieses Changelog verfolgt jede Änderung an der WOHNO-REST-API (/api/v1). Die API ist als v1 versioniert und entwickelt sich additiv weiter — neue Felder, Endpoints und Scopes brechen niemals bestehende Integrationen. Die Regeln dahinter (Deprecation-Fenster, DTO-Versionierung) findest du in der Versionierung & Deprecation-Policy.

Jeder Eintrag listet das Datum, die Welle, mit der er ausgeliefert wurde, die neuen Endpoints und die neuen Scopes. Sofern nicht anders vermerkt, ist jede Änderung rein additiv.

Dark-shipped vs. GA: Manche Ressourcen sind implementiert und hinter einem Feature-Flag (*_PUBLIC_API_ENABLED) live, aber noch nicht allgemein verfügbar (GA). Sie sind hier aus Transparenzgründen dokumentiert; die Verfügbarkeit für deinen Key hängt vom Flag und einem etwaigen ressourcenspezifischen Gate ab.

2026-06 — Owner-Zuweisung für Inserate

Hinzugefügt

  • POST /api/v1/listings akzeptiert ein optionales owner_email-Feld. Es weist das neue Inserat diesem Team-Mitglied zu (statt dem Ersteller des API-Keys), sofern die E-Mail zu einem Mitglied derselben Organisation gehört (Rolle owner, admin oder member). Wirkt nur beim Create; wird bei external_ref-Upsert und PATCH ignoriert.

Hinweise

  • Rein additiv — ohne owner_email bleibt das bisherige Verhalten (der Key-Ersteller wird Owner).
  • Eine unbekannte E-Mail und ein Nicht-Mitglied liefern dieselbe 403 FORBIDDEN — das Feld kann nicht zur Enumeration von WOHNO-Konten genutzt werden.
  • Verwendung siehe Inserate aus deinem CRM synchronisieren.

2026-05 — Analytics & Usage (Welle 5)

Hinzugefügt

  • GET /api/v1/usage — Quota- und Usage-Self-Service für die eigene Organisation. Scope usage:read (nur Secret Keys). GA-ready (nur eigene Daten).
  • GET /api/v1/analytics/listings/{id} — aggregierte Inserats-Analytics (org-isoliert, keine PII). Scope analytics:read (nur Secret Keys). Dark-shipped, bis der Performance-Test unter Produktionslast abgeschlossen ist.

Hinweise

  • Beide Endpoints sind ausschließlich Secret-Key (sk_) und von Publishable Keys ausgeschlossen.
  • Additiv: keine Änderungen an bestehenden Endpoints oder Antwort-Formen.

2026-04 — Utility & Discovery (Welle 4)

Hinzugefügt

  • POST /api/v1/wbs/check — zustandsloser WBS-(Wohnberechtigungsschein-) Eignungs-Schnellcheck. Scope wbs:check, Publishable-Key erlaubt (browser-sicher). GA-ready.
  • GET /api/v1/discovery/listings — diskrete, organisationsübergreifende Inserats-Discovery mit ETag-Unterstützung. Scope discovery:read, Publishable-Key erlaubt. Dark-shipped.
  • POST /api/v1/matching/score — Matching-Score as a Service (Premium). Scope matching:score (nur Secret Keys), nur aggregierte Ausgabe. Dark-shipped.

Hinweise

  • Nur additiv. wbs:check und discovery:read sind die ersten Publishable- (pk_-)Scopes seit den Read-Endpoints; matching:score bleibt sk_-only.

2026-03 — Applications / Bewerbungen (Welle 3)

Status: dark-shipped — NICHT GA. Diese Ressource verarbeitet Bewerber-PII. Sie ist implementiert und hinter ihrem Feature-Flag live, aber die allgemeine Verfügbarkeit ist bis zu einem DSGVO-Review und einem Consent-Gate blockiert. Baue nicht in der Annahme eines GA-Zeitpunkts dagegen.

Hinzugefügt

  • GET /api/v1/listings/{id}/applications — Bewerbungen für ein Inserat auflisten. Scope applications:read (nur Secret Keys).
  • GET /api/v1/applications/{id} — eine einzelne Bewerbung lesen (reduziertes, whitelistetes DTO). Scope applications:read (nur Secret Keys).
  • PATCH /api/v1/applications/{id} — Bewerbungs-Status / -Tags aktualisieren. Scope applications:write (nur Secret Keys).

Hinweise

  • Nur Secret-Key (sk_); es gilt ein Doppel-Gate (Feature-Flag und Consent).
  • Reduziertes ApplicationPublicDto und Audit-Logging pro Lesezugriff schützen die Bewerber-PII.
  • Additiv: keine Änderungen an bestehenden Endpoints.

2026-02 — Listings-Write & Syndication (Welle 2)

Hinzugefügt

  • POST /api/v1/listings — Inserat erstellen / upserten (unterstützt external_ref und Idempotency-Key). Scope listings:write (nur Secret Keys).
  • PATCH /api/v1/listings/{id} — ein Inserat aktualisieren. Scope listings:write.
  • DELETE /api/v1/listings/{id} — ein Inserat löschen. Scope listings:delete.
  • POST / DELETE /api/v1/listings/{id}/images — Bild-Upload und -Entfernung per Signed-URL. Scope listings:write.

Hinweise

  • Die zuvor nur lesende Listings-Ressource erhielt Schreiboperationen — additiv, die bestehenden GET-Endpoints und der listings:read-Scope bleiben unverändert.
  • Write-Endpoints akzeptieren einen Idempotency-Key-Header, sodass wiederholte Bulk-Writes sicher sind. Dark-shipped.

2026-01 — Webhooks, API-Keys & Members (Welle 1)

Hinzugefügt

  • POST /api/v1/webhooks, GET/PATCH/DELETE /api/v1/webhooks/{id} — Webhook-Subscriptions verwalten (die Delivery-Pipeline, HMAC-Signierung und Event-Typen existierten bereits). Scopes webhooks:read / webhooks:write.
  • GET /api/v1/webhooks/{id}/deliveries und POST .../deliveries/{deliveryId}/redeliver — Delivery-Log + Re-Delivery.
  • GET/POST /api/v1/api-keys, GET/DELETE /api/v1/api-keys/{id} — die eigenen API-Keys programmatisch verwalten. Scopes api-keys:read / api-keys:write.
  • GET/POST /api/v1/organizations/{id}/members und PATCH/DELETE /api/v1/organizations/{id}/members/{userId} — Team-Mitglieder verwalten. Scopes members:read / members:write.

Hinweise

  • Alle Endpoints der Welle 1 sind ausschließlich Secret-Key (sk_) und von Publishable Keys ausgeschlossen. Dark-shipped.
  • Diese Scopes (webhooks:*, api-keys:*, members:*) waren zuvor definiert, hatten aber keine Endpoints; diese Welle hat sie aktiviert. Nur additiv.