POST /v1/events {"channel":"zahlungen","title":"Neues Abo"}
{ "channel": "zahlungen", "title": "Neues Abo", "description": "Pro-Tarif, 9 EUR", "zeit": "2026-08-30T15:04:22Z" }
Seit Dienstag scheitert im Checkout jede Kartenzahlung, und du erfährst es am Freitag — von einem Kunden, der sich beschwert. Die entscheidende Zeile stand die ganze Zeit im Serverlog, zwischen vierzigtausend anderen, die niemand liest. Drei Tage Umsatz sind weg, und die Leute, die es zweimal vergeblich versucht haben, kommen nicht wieder.
Die brauchbarste Auswahlregel ist keine Geschmacksfrage, sondern eine Rechnung: Der Strom hält 2.000 Ereignisse je Schlüssel. Was du täglich hundertfach meldest, verdrängt binnen drei Wochen alles andere — und zwar über Kanalgrenzen hinweg, denn die 2.000 gelten für alle Kanäle zusammen. Ein lauter Kanal schiebt also einen leisen aus dem Speicher. Sortiere deshalb nach Frequenz, nicht nach Wichtigkeit:
| Meldung | wie oft am Tag | wohin damit |
|---|---|---|
| „Rückbuchung eingegangen, 149 €“ | einzelne | hierhin, mit Benachrichtigung |
| „Kündigung: anna@firma.de“ | einzelne | hierhin |
| „Nächtlicher Abgleich beendet, 12 Fehler“ | einmal | hierhin |
| „GET /preise 200 in 12 ms“ | zehntausende | Serverlog |
| „Besucher hat /preise aufgerufen“ | tausende | Reichweitenmessung |
| „Backup gestartet“ | einmal — interessant ist nur das Ausbleiben | Cron-Wache |
| „Seite antwortet nicht“ | hoffentlich nie | Uptime-Wache, die misst genauer und schneller |
Für die Mail-Benachrichtigung gilt eine schärfere Regel: nur bei Ereignissen, bei denen du deinen Tag tatsächlich umplanen würdest. Der Schalter sitzt am einzelnen Ereignis, nicht am Kanal — du entscheidest also beim Senden, nicht beim Einrichten. Es geht eine Mail je Ereignis raus, ohne Sammlung und ohne Bremse: Wer am Starttag jede Anmeldung meldet, hat abends vierhundert Mails im Postfach und liest ab der dreißigsten keine mehr. Im Betreff stehen Kanal und Titel, getrennt durch einen Doppelpunkt — damit lässt sich im Mailprogramm sauber filtern, ohne dass du eine Regel je Ereignisart brauchst.
Der Strom ist bewusst klein gehalten. Alles, was darüber hinausgeht, gehört in deine eigene Datenbank.
| Größe | Grenze |
|---|---|
| Ereignisse je Schlüssel | 2.000 über alle Kanäle — danach fällt das älteste heraus |
| Titel | 200 Zeichen |
| Beschreibung | 2.000 Zeichen |
| Kanalname | 60 Zeichen |
| Symbol | 8 Zeichen |
| Merkmale (Tags) | 10 Paare, Name 40 und Wert 200 Zeichen |
| Abruf je Anfrage | Standard 100, höchstens 500 |
Rechne das auf deinen Betrieb um, bevor du dich darauf verlässt: Bei zwanzig Ereignissen am Tag reichen die 2.000 Plätze für rund hundert Tage, bei zweihundert am Tag für zehn. Längere Titel, Beschreibungen und Merkmalswerte werden nicht abgelehnt, sondern stillschweigend abgeschnitten — wenn dein Titel die Bestellnummer enthält, setz sie nach vorn. Das hier ist ein Strom, kein Archiv. Was du aufheben musst — Rechnungsdaten, Vertragsänderungen, erteilte Einwilligungen — gehört in dein eigenes System; hier steht nur der Hinweis, dass es passiert ist.
Beim Abruf bekommst du das Neueste zuerst, wahlweise gefiltert nach Kanal; der Kanalname muss dabei exakt stimmen. Eine Volltextsuche gibt es nicht, einen Zeitraumfilter auch nicht — wer im Bestand suchen will, holt sich die letzten 500 und sucht selbst. Benachrichtigt wird ausschließlich per Mail an die Adresse, die zum Schlüssel hinterlegt ist: kein Slack, kein Webhook, keine SMS.
Server-Logs sind für Entwickler und voller Rauschen. Das Ereignis-Log ist die kuratierte Geschäftssicht: nur die Ereignisse, die zählen — neue Anmeldung, Zahlung fehlgeschlagen, Import fertig — sauber nach Kanälen sortiert und auch für Nicht-Techniker lesbar.
Ein POST mit Kanal und Titel, optional Beschreibung und Icon. Aus jeder Sprache, jedem Framework, jedem Webhook heraus — überall, wo ein HTTP-Aufruf möglich ist.
Ja, je Kanal: Ereignisse mit notify-Flag lösen eine E-Mail aus. So bleibt "Zahlung fehlgeschlagen" nicht bis zum nächsten Dashboard-Besuch liegen.
So viele du brauchst — üblich ist ein Kanal je Projekt oder je Ereignisklasse (zahlungen, anmeldungen, fehler). Kanäle entstehen automatisch beim ersten Ereignis, ohne Vorab-Konfiguration.
Ja — jeder Dienst, der Webhooks senden kann, kann Ereignisse melden. Ein POST mit JSON-Körper genügt, damit funktionieren auch No-Code-Automationen sofort.
Aktuell ist alles in der Beta komplett kostenlos — keine Kreditkarte, keine Laufzeit. Nach dem Verkaufsstart beginnen die Tarife bei 3,50 € pro Monat (50.000 Aufrufe) — bewusst rund die Hälfte des üblichen Marktpreises. Wer in der Beta dabei ist, wird vor jeder Umstellung informiert.
E-Mail-Adresse in das Formular auf dieser Seite eintragen — der API-Schlüssel erscheint sofort, ohne Bestätigungs-Wartezeit. Damit hast du 1.000 Aufrufe pro Monat frei. Der Schlüssel wird als Hash gespeichert und nur einmal angezeigt, also direkt sicher ablegen.
E-Mail eintragen, Schlüssel erscheint sofort auf der Seite. Kein Konto, keine Kreditkarte, keine Freischaltung durch uns.
Ein einziger HTTP-Aufruf mit deinem Schlüssel im Kopf — aus jeder Programmiersprache, jedem Framework, jedem Automatisierungswerkzeug.
Du bekommst sauberes JSON oder die fertige Datei zurück. Fehler kommen als klare deutsche Meldung, nicht als Rätsel.
POST /v1/events {"channel":"zahlungen","title":"Neues Abo"}
Wir legen die Preise jetzt schon offen, damit du planen kannst. Beta-Nutzer werden rechtzeitig informiert, bevor sich etwas ändert — niemand wird automatisch in einen bezahlten Tarif überführt.
Alle Preise zuzüglich Umsatzsteuer. Monatlich kündbar, keine Mindestlaufzeit, keine Einrichtungsgebühr.
Verwandt: Web-Analytik · Kurz-URLs · Warteliste · Kürzel – Textbausteine