Der erste eigene Fleißbot

Bot-API · Stand: August 2026

Ein Fleißbot ist alles, was einen HTTP-POST senden kann. Ein n8n-Workflow, ein Make-Szenario, ein Shell-Skript auf einem Server im Regal, ein Agent – was auch immer bei Ihnen die Fleißarbeit macht. Diese Seite zeigt die komplette Schnittstelle. Sie ist bewusst klein: eine URL, ein Token, ein JSON.

Sie bauen mit einem KI-Assistenten? Geben Sie ihm fleissbots.adlx.de/llms.txt – dort steht dieselbe Schnittstelle maschinenlesbar, mit Beispielen. Ein Satz wie „Bau mir einen Bot, der mir jeden Morgen X meldet“ reicht dann als Anforderung.

Was Sie brauchen

• Die Fleißbots-App auf Ihrem Telefon, angemeldet mit dem Zugangscode ADLX-TEST – so geht’s.
• Einen Bot in Ihrem Leitstand mit zugehörigem Bot-Token. Den legen Sie selbst an: im Chat mit dem ADLX-Bot auf „Eigenen Fleißbot anlegen“, Namen sagen, fertig. Sie bekommen einen Link zu Ihrem Starter-Kit mit Token und fertigen Beispielen – der Link gilt 24 Stunden.

Das Bot-Token ist ein Geheimnis wie ein Passwort: Es gehört in eine Umgebungsvariable oder einen Credential-Speicher, nie in Quelltext oder Chat-Verläufe. Serverseitig speichern wir es nur als Hash.

In zwei Aufrufen zur ersten Nachricht

Basis-URL ist https://api.fleissbots.adlx.de, authentifiziert wird mit Authorization: Bearer <BOT_TOKEN>. Erst holt sich der Bot seine Konversationen (je Nutzer in Ihrem Leitstand eine), dann sendet er hinein:

# 1. Wohin darf der Bot senden?
curl -s https://api.fleissbots.adlx.de/api/v1/bot/conversations \
  -H "Authorization: Bearer $BOT_TOKEN"
# → [{ "conversation_id": "…", "user": { "display_name": "…" }, … }]

# 2. Melden.
curl -s https://api.fleissbots.adlx.de/api/v1/bot/messages \
  -H "Authorization: Bearer $BOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "conversation_id": "HIER-DIE-ID-AUS-SCHRITT-1",
    "type": "text",
    "text": "Der erste Fleißbot meldet sich."
  }'

Das war der ganze Weg. Die Nachricht liegt jetzt in der App, der Push ist unterwegs – Ihr Telefon meldet sich.

Die drei Bausteine

Melden

type: "text" mit Markdown-Teilmenge (fett, kursiv, Links, Listen). Was wirklich dringend ist, bekommt "priority": "critical" – das wird auf dem iPhone als zeitkritische Mitteilung zugestellt und durchbricht Fokus-Modi. Sparsam einsetzen: Ein Fleißbot, der ständig ruft, wird stummgeschaltet.

Nachfragen

Steht eine Entscheidung an, sendet der Bot Schaltflächen – und bekommt die Antwort an seinen Webhook zurück (siehe unten). Mit "task": true wird daraus eine offene Aufgabe: Die App zeigt „1 offen“, bis die Frage beantwortet ist, und der kurze title steht immer sichtbar oben, die Details darunter zum Aufklappen.

{
  "conversation_id": "…",
  "type": "buttons",
  "title": "Rechnung R-2231 weicht ab",
  "text": "Betrag 4.180 € statt 3.600 € laut Angebot. Wie verfahren?",
  "buttons": [
    { "id": "freigeben", "label": "Freigeben" },
    { "id": "pruefen",   "label": "Prüfen lassen" }
  ],
  "task": true
}

Ein Tap erledigt die Aufgabe sofort; jede Antwort erreicht Ihren Webhook genau einmal, ein zweiter Tap wird abgewiesen. Wird die Frage anderswo entschieden – am Rechner, per Mail, oder sie hat sich von selbst erledigt –, schließt der Bot sie mit POST /api/v1/bot/messages/<id>/resolve und einem kurzen Label ({"label": "Freigegeben (am Rechner)"}). Der Aufruf ist idempotent: Wer zuerst erledigt, bestimmt, was in der App steht. Eine Bestätigung wie „✔ notiert“ braucht es nicht – die App zeigt die erledigte Frage selbst.

Anhängen

type: "file" (oder image, audio) mit attachment_url: Das Gateway lädt die Datei serverseitig herunter und legt sie im eigenen Speicher in Deutschland ab – die App bekommt nie fremde URLs zu sehen. Auch data:-URIs funktionieren; damit lassen sich z. B. Visitenkarten (vCard) direkt im Workflow erzeugen und mitschicken, ohne irgendwo eine Datei zu hosten. Ein begleitender text wird mit dem Anhang angezeigt.

Eingehende Nachrichten empfangen

Ein Fleißbot darf auch zuhören: Schreibt der Nutzer ihm (oder tippt eine Schaltfläche), stellt das Gateway die Nachricht per POST an die Webhook-URL des Bots zu – signiert, mit automatischen Wiederholversuchen. Der Rumpf sieht so aus:

{
  "message_id": "…",
  "conversation_id": "…",
  "tenant_id": "…",
  "user": { "id": "…", "display_name": "…" },
  "timestamp": "2026-08-19T09:30:00.000Z",
  "type": "text",              // oder "button_reply", "image", "file", "audio"
  "text": "…",
  "button_reply": {            // nur bei type "button_reply"
    "id": "pruefen",
    "label": "Prüfen lassen",
    "in_reply_to": "message_id der Schaltflächen-Nachricht"
  },
  "attachment": { "url": "kurzlebige Download-URL", … }   // nur bei Medien
}

• Signatur prüfen: Header x-adlx-signature ist HMAC-SHA256 (hex) über den rohen Request-Body, Schlüssel ist das Webhook-Secret Ihres Bots. So ist sicher, dass die Nachricht wirklich vom Gateway kommt.
• Schnell mit 200 antworten, die eigentliche Arbeit asynchron erledigen und die Antwort über POST /api/v1/bot/messages senden.
• Bestätigen ohne Extra-Nachricht: Ist die Nachricht verarbeitet, quittiert POST /api/v1/bot/messages/<message_id>/ack sie – die App zeigt dann farbige Doppel-Häkchen statt einer eigenen „Angenommen.“-Blase. Grau werden die Häkchen von selbst, sobald Ihr Webhook mit 200 geantwortet hat.
• Dauert die Arbeit spürbar, zeigt POST /api/v1/bot/typing ({ "conversation_id": "…" }) dem Nutzer ein flüchtiges „tippt …“ – ohne etwas zu speichern.

Ein rein proaktiver Bot (Monitoring, Digest, Nachtlauf-Report) braucht keinen erreichbaren Webhook – er nutzt nur die zwei Aufrufe aus dem Schnellstart.

Die Schnittstelle im Überblick

Alle Pfade sind ratenbegrenzt; bei 429 mit Wartezeit erneut versuchen. Push-Mitteilungen transportieren nie Klartext – das Gerät lädt Inhalte selbst nach. Mehrere Nachrichten kurz hintereinander bündelt das Gateway: ein Push sofort, einer für alles, was in der folgenden Minute nachkommt. Nachrichten werden nach 30 Tagen automatisch gelöscht, Anhänge eingeschlossen.

Ohne Code: die E-Mail-Adresse

Der schnellste Fleißbot braucht gar keinen HTTP-Aufruf: Jeder Bot bekommt auf Wunsch eine geheime Einliefer-Adresse (etwa k7f3…@mail.fleissbots.adlx.de). Was ein System dorthin mailt – Asana, Shop, Buchhaltung, Alarmanlage – wird geprüft und als Meldung zugestellt. Angenommen werden nur Absender Ihrer Freigabeliste, die zusätzlich SPF oder DKIM bestehen; Anhänge und technische Kopfzeilen werden verworfen, gespeichert wird nur Absender, Betreff und Textauszug. Die Adresse legt Ihr ADLX-Bot im Chat an, direkt nach dem Anlegen eines eigenen Fleißbots.

Rezept: Fehlerwarner für n8n

n8n kennt für jeden Workflow einen Error Workflow, der bei einem Fehlschlag anläuft. Meist verschickt er eine Mail, die im Posteingang untergeht. Als Fleißbot besteht er aus drei Knoten: Error Trigger → GET /api/v1/bot/conversations → POST /api/v1/bot/messages. Der Error Trigger liefert Workflow-Name, Fehlermeldung, den letzten Schritt und den Link zur Ausführung – genau das wird zur Meldung:

{
  "conversation_id": "{{ $json.conversation_id }}",
  "type": "text",
  "priority": "critical",
  "text": "**Workflow-Fehler: Rechnungs-Export**\nRequest failed with status 502\n\nSchritt: Buchhaltung API\n[Ausführung öffnen](https://n8n.example/…)"
}

Workflow als JSON herunterladen, in n8n importieren, in beiden HTTP-Knoten eine Credential vom Typ „Bearer Auth" mit dem Bot-Token wählen und den Workflow in den Einstellungen jedes zu überwachenden Workflows als Error Workflow eintragen. Einmal, für alle. Für Make oder Zapier gilt dasselbe Muster mit deren Fehler-Routen.

Und wenn Sie nicht bauen wollen

Dann lassen Sie machen. Wir bauen Fleißbots für Kunden – vom Lead-Melder bis zum Nachtlauf-Report. Anregungen dafür stehen im Rezept-Katalog; schreiben Sie uns, was beobachtet werden soll.