Backlog

Sortiert nach Wert, nicht nach Reihenfolge des Einfalls. Jeder Punkt sagt,

was das Problem ist und woran man merken würde, dass es gelöst ist.

1 · Änderungen an inoffiziellen APIs bemerken, bevor sie wehtun

Das Problem: Superchat, Zapier und die anderen können ihre internen APIs

jederzeit ändern, ohne jemanden zu informieren. Heute läuft alles, morgen

antwortet ein Endpunkt anders, und wir merken es an einem fehlgeschlagenen

Versand statt an einer Warnung.

Was es schon gibt: ~/api-lab/cdp/openapi_from_journal.py erzeugt aus den

Mitschnitten eine OpenAPI-Spec pro Host (~/api-lab/openapi-generated/) und

schreibt einen REPORT.md, der ausweist, was gegenüber den Living-Docs neu oder

widersprüchlich ist.

Was fehlt:

Regelmäßiger Lauf (Cron), nicht nur wenn jemand daran denkt.
Ein Verlauf: heute weiß niemand, wie oft sich etwas ändert. Genau das wäre

die interessante Zahl. Vorschlag: bei jedem Lauf die Spec versionieren und die

Unterschiede protokollieren.

Eine Meldung, wenn sich etwas ändert, das wir aktiv benutzen. Eine Änderung

an einem Endpunkt, den niemand ruft, ist Rauschen.

Fertig, wenn: eine Änderung an einem benutzten Endpunkt eine Meldung erzeugt,

bevor sie einen Lauf kaputtmacht.

2 · Übersicht über die erzeugten API-Specs

Das Problem: Die Specs liegen als JSON auf der Platte. Niemand schaut hinein,

also nützen sie nur dem, der weiß, dass es sie gibt.

Optionen, noch nicht entschieden:

ClientShare (statisch, kostenlos, schon da) — würde für Ansehen reichen.
Eigene Instanz auf Coolify mit einem fertigen Betrachter, etwa Scalar,

Redoc oder Swagger UI. Mehr Komfort, mehr Wartung.

Nichts eigenes, sondern die Specs in die Living-Docs verlinken.

Zuerst zu klären, bevor man baut: Wer schaut da wirklich rein und wozu?

Wenn die Antwort „ein Agent, der einen Endpunkt sucht" ist, braucht es keine

Oberfläche, sondern eine gute Suche über die JSON-Dateien.

3 · Zeitversand in Superchat wirklich auslösen

Gemessen am 02.08.2026, alle drei Befunde belegt:

scheduling: {type: SCHEDULED, value, timezone} lässt sich per PUT setzen. ✅
Ein so geplanter Entwurf feuert NICHT von allein — acht Minuten über der

Zeit stand er noch auf DRAFT, nichts zugestellt.

POST /send sendet sofort und ignoriert den Zeitplan.

Offen: Wie aktiviert die Oberfläche einen Zeitplan? Es muss einen Weg geben,

die Reminder-Kampagne vom 09.06.2026 ist planmäßig gelaufen (296 zugestellt).

Nächster Schritt: einmal in der Oberfläche eine geplante Kampagne abschicken

und den Mitschnitt lesen. Genau so wurden PATCH /name und channelId gefunden.

Solange offen: den Takt selbst fahren. Funktioniert, ist belegt, und gibt

zwischen Vorbereiten und Feuern einen Kontrollpunkt.

4 · Mitschnitt legt keine neue Tagesdatei an

Gemessen 02.08.2026: cdp_capture.py berechnet den Dateinamen **einmal beim

Start**. Ein Recorder, der gestern Abend startete, schreibt heute noch in die

Datei von gestern. Nichts geht verloren, aber wer nach dem heutigen Datum sucht,

findet nichts und hält es für eine Lücke. Genau das ist mir passiert.

Fix: vor jedem Schreiben das Datum prüfen und bei Tageswechsel umschwenken.

Klein, aber es verfälscht sonst jede Suche nach Datum.

5 · Kampagnen lassen sich nicht löschen

DELETE gibt 405 auf /v1 und /v5. Testreste bleiben stehen. Behelf:

umbenennen auf ZZ … (loeschbar). Zu prüfen, ob die Oberfläche einen Weg hat

(dann kartieren, so wie bei PATCH /name).

6 · Aufsetz-Phase für Marke Nummer 2

Das Runbook beschreibt einen Wiederhol-Vorgang. Für einen neuen Kunden fehlt

alles davor: Messenger-Konto, WhatsApp-Kanal und Meta-Verifizierung,

Vorlagen-Genehmigung (Tage Vorlauf), Bau der Automationen. Das ist der größte

Brocken und der eigentliche Blocker für die Skalierung auf Domis Kundenstamm.

Erledigt (bleibt als Beleg stehen)

✅ Kampagne umbenennen — eigener Endpunkt PATCH /v5/campaigns/{cp}/name,

funktioniert auch nach dem Versand. PUT auf die Kampagne ist dort gesperrt (409).

Gefunden, indem Benedikt es einmal in der Oberfläche gemacht hat.

✅ Schreibform des Kampagnen-PUT — channelId (nicht messageChannelConfigId)

und content.templateId (nicht das Vorlagen-Objekt).

✅ Qualitätsbewertung des WhatsApp-Kontos — GET /v1/message-channels/{mc_},

Feld whatsAppDetails.phoneNumber.qualityRating.

✅ Aufbewahrung der Mitschnitte nach Läufen — mitschnitt-aufraeumen.py,

sechs Läufe je Browser, ältere werden verdichtet.