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.
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:
die interessante Zahl. Vorschlag: bei jedem Lauf die Spec versionieren und die
Unterschiede protokollieren.
an einem Endpunkt, den niemand ruft, ist Rauschen.
Fertig, wenn: eine Änderung an einem benutzten Endpunkt eine Meldung erzeugt,
bevor sie einen Lauf kaputtmacht.
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:
Redoc oder Swagger UI. Mehr Komfort, mehr Wartung.
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.
Gemessen am 02.08.2026, alle drei Befunde belegt:
scheduling: {type: SCHEDULED, value, timezone} lässt sich per PUT setzen. ✅ 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.
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.
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).
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.
Die Idee. Der Reminder braucht je Empfänger dessen persönlichen
WebinarJam-Raumlink. Heute (04.08.2026) haben wir ihn nachträglich geholt:
4.987 Links über POST api.webinarjam.com/everwebinar/registrants gezogen, per
E-Mail den Superchat-Kontakten zugeordnet und in ein Kontaktfeld geschrieben.
Das funktioniert, ist aber ein Nachlauf mit Lücke: wer sich nach dem Durchlauf
anmeldet, hat kein Feld und fällt aus der Kampagne.
Der saubere Weg. Der Zapier-Schritt, der die Person in WebinarJam
registriert, bekommt in seiner Antwort bereits live_room_url zurück. Schriebe
der Zap diesen Wert direkt ins Superchat-Kontaktfeld, wäre das Feld immer
aktuell: kein Ziehskript, kein Nachschreiben, keine Lücke, und jede Kampagne
könnte sich jederzeit darauf verlassen.
⚠️ Warum es NICHT sofort gebaut wurde (Benedikt, 04.08.2026): mögliche
Race Condition. In dem Moment, in dem der Zap die Registrierungs-Antwort
hat, ist nicht sicher, dass der Kontakt in Superchat schon existiert — den
legt ein anderer Zweig (FIND_OR_CREATE_CONTACT im Superchat-Workflow) an. Wer
zu früh schreibt, schreibt ins Leere oder erzeugt einen Doppelkontakt.
Vor dem Bau zu klären: Reihenfolge und Garantien der beiden Zweige. Entweder
der Zap wartet auf den Kontakt (Retry/Lookup), oder das Feld wird im
Superchat-Workflow gesetzt, der den Kontakt ohnehin selbst anlegt und den Link
per HTTP-Node nachholen könnte. Erst wenn das geklärt ist, ist es sicher.
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.
channelId (nicht messageChannelConfigId) und content.templateId (nicht das Vorlagen-Objekt).
GET /v1/message-channels/{mc_}, Feld whatsAppDetails.phoneNumber.qualityRating.
mitschnitt-aufraeumen.py,sechs Läufe je Browser, ältere werden verdichtet.