Öffentliche v1-API
Rund 565 Endpunkte unter /api/v1, Anmeldung per JWT-Bearer-Token, einheitliche Antwort-Hülle {success, data}
Funktionen · Plattform & Betrieb
Hier ist beschrieben, wie DiKAS mit anderen Programmen spricht. Nach aussen gibt es zwei Wege: die moderne Schnittstelle unter /api/v1, die mit einem Anmelde-Token arbeitet und in einer durchsuchbaren Online-Referenz dokumentiert ist, und eine ältere Schnittstelle unter /rest/, die noch mit festen Zugangsschlüsseln arbeitet und vor allem für bestehende Fremdsysteme da ist (Warenwirtschaft, Kartenautomaten, Telefonanlage, Online-Bestellportale). Dazu kommen fertige Anbindungen, die der Betrieb selbst einschalten kann: Bestellungen per WhatsApp, Artikelpflege in einer Google-Tabelle, Adressvervollständigung beim Anlegen von Kunden und mehrere KI-Hilfsfunktionen wie „Speisekarte abfotografieren und Artikel daraus erzeugen". Anbindungen an Lieferportale, Banken, Kassensicherungs- und Zahlungsanbieter sind bewusst nicht hier, sondern in den jeweiligen Fachbereichen.
Schnittstellenzugänge kontrolliert verwalten.
Echte Oberfläche
Keine Stockmotive: Die Aufnahmen stammen aus den reproduzierbaren DiKAS-Demos und zeigen die jeweilige Funktion im Produkt.
Vollständiger Überblick
Alle folgenden Punkte stammen aus dem gegen den Programmcode geprüften Funktionskatalog.
Rund 565 Endpunkte unter /api/v1, Anmeldung per JWT-Bearer-Token, einheitliche Antwort-Hülle {success, data}
Durchsuchbare Endpunkt-Referenz unter /swagger, inkl. „Authorize"-Knopf zum Ausprobieren
Entscheidet, welche Controller als „öffentliche Entwickler-API" gelten und welche verborgen bleiben
Idempotency-Key-Kopfzeile: derselbe Schlüssel innerhalb einer Stunde liefert das erste Ergebnis erneut, statt doppelt zu buchen
Kompatibilitäts-Ebene für bestehende Fremdsysteme, PascalCase-JSON, Schlüssel im URL-Pfad; historische Request-Bodies mit einfachen statt doppelten JSON-Quotes werden vor der Modellbindung normalisiert
Schlüssel anlegen, umbenennen, löschen, neuen Schlüssel erzeugen; je Schlüssel genau eine Zugriffsart
Zieht den Schlüssel aus dem {key}-Pfadsegment und prüft ihn gegen die erlaubten Zugriffsarten
POST /rest/erp/import/{key} — Artikel und Warengruppen aus einem ERP übernehmen, wahlweise im Ersetzen-Modus; der Alt-Endpunkt toleriert fehlende/kaputte optionale Gruppendaten und historisches Pseudo-JSON mit einfachen Quotes
Artikel per PLU einzeln oder als Stapel buchen, Kartenkonto abfragen und Preis abfragen. POST /rest/cp/addcard/{key} legt offene Bons an; ?new=1 erzeugt eine unbekannte PLU genau einmal in der Hauptgruppe. Die Kasse springt bei einer Arbeitsplatz-Buchung aus einer Fremdseite nach Direktverkauf und nach vollständiger Zahlung einmalig zur selben Fremdseite zurück; bei Restbons oder manuellem Verlassen bleibt bzw. verfällt das Ziel. Legt der Kunde vor dem Kassieren eine freie NFC-Karte auf, legt die Kasse daraus einen Bonuskarten-Kunden an und nimmt ihn als Kunden der Zahlung mit. Optional fragt sie in beiden Reihenfolgen „Karte, dann Kunde" und „Kunde, dann Karte", ob die freie Karte zum gewählten Kunden verschoben werden soll. Eine WebHookUrl wird nach erfolgreichem Kassieren mit dem Legacy-Beleg und beim Storno eines unbezahlten Bons mit Comment=Storno/negativer Menge aufgerufen. addcard/{key}/{cardId} kassiert dagegen unmittelbar vom Kartenkonto.
Kunden suchen; bis zu 500 Änderungen strikt nach einem Cursor abholen (GET /rest/extern/customer/{key}/changes/{date}, Classic-Formate yyyyMMdd, yyyyMMddHHmm, yyyyMMddHHmmss in lokaler Serverzeit); Karten-ID und Gesamtsaldo aus Bar-/Bonusguthaben lesen; deaktivierte Kunden kommen als IsDeleted=true; Guthaben prüfen; Umsatzliste
Guthaben aufladen/abbuchen, reservieren, offenen Betrag lesen, einlösen und Buchungsverlauf nach Zeitraum abrufen; der Verlauf akzeptiert die Classic-Datumsformate yyyyMMdd, yyyyMMddHHmm, yyyyMMddHHmmss in lokaler Serverzeit. Seit 20.08.2026 Classic-kompatibel: allocation liefert die AllocationId auch in Message, redeem nimmt Betrag ODER AllocationId, cancel/redeem finden eine offene Reservierung auch über die als Comment mitgeschickte Fremd-Referenz, und changelist liefert SettledDate/IsOpenAllocation
Gutschein anlegen, abfragen, einlösen
Kartendaten, Transaktionen, Gastinfo und Kartenfreigabe für Automaten und Schankanlagen
Artikelliste, Tische, Drucker lesen; Bestellung anlegen, öffnen, bezahlen; Nachricht an einen Tisch
Belege nach Bon-Nummernbereich oder Datumsbereich abholen
phonebook.xml für die Fritz!Box und all.vcf als Kontaktdatei aus dem Kundenstamm
Der Server verbindet sich mit dem Anrufmonitor der Box (<host>:1012, an der Box mit #965 einschalten), liest RING/DISCONNECT, ordnet den Anrufer per Rufnummer dem Kunden zu (PhoneNumberNormalizer, dieselbe Regel wie die Kundensuche) und meldet IncomingCall { phoneNumber, matchedCustomerId?, matchedCustomerName? } per SignalR an die Kassen; das Anruf-Popup führt mit „Annehmen" in den Telefon-Modus (05). Einstellung im Backoffice (Hardware → Anrufer-Erkennung: Host, Ein/Aus, Verbindungstest, Status verbunden/getrennt) oder — für die Appliance — Telephony:FritzBox:Host in der Einstellungsdatei. Wiederverbindung mit Backoff 5–60 s; nur Nummer und Zeitpunkt im Speicher, nichts wird persistiert; nur lokal/Einzelmandant
Nimmt Bestellungen des Portals GloriaFood entgegen und legt Lieferaufträge an
Eingehende Nachricht entgegennehmen, Antwort zurückgeben, ausgehende Nachrichten als Postausgang bereitstellen und quittieren
Kopplungs-Sitzung starten und QR-Code im Dialog anzeigen, bis „Verbunden" gemeldet wird
KI ordnet den freien Text der Online-Karte zu, fragt bei Unklarheit nach und legt sonst eine normale Online-Bestellung an
Kunde verknüpft im Portal ein Google-Sheet; Artikel und Warengruppen werden in beide Richtungen abgeglichen
Google meldet „Datei geändert"; der Eintrag wird nur als schmutzig markiert, der Abgleich läuft entprellt im Hintergrund
Entprellt (10 s Ruhe, spätestens 60 s), erneuert Google-Kanäle, stündlicher Vollabgleich als Sicherheitsnetz
Adressvorschläge während der Eingabe, Adresse zu Koordinaten auflösen, Ortsdetails abrufen
GET /api/v1/config/order-base-url liefert shopUrl und reservationUrl als kanonische Links für Subdomain- und Pfadmodus; die Betriebs-Einstellungen erklären das Hinterlegen des Reservierungslinks bei Google
Foto oder PDF einer Karte wird zu Artikeln mit Name, Preis, Gruppe und Steuersatz-Vorschlag
Schlägt zu den Spaltenüberschriften einer Importdatei die passenden DiKAS-Felder vor
Schlägt zu einem Artikelnamen Allergene bzw. einen Beschreibungstext vor
Aus dem Foto eines Eingangsbelegs Gesamtbetrag, Steueraufteilung, Datum, Aussteller, Rechnungsnummer, Positionen und Kategorie-Vorschlag ziehen
Aus Restposten und dem eigenen Artikelstamm zwei Gerichtsideen bauen (Task-Alias text-cheap); Kalkulation und Übernahme liegen im Artikelbereich
Standardweg über den DiKAS-Dienst ai.dikas.de; der Betrieb braucht keinen eigenen Anbieter-Schlüssel
Betrieb hinterlegt stattdessen Anbieter, Adresse, Modell und Schlüssel selbst (z. B. selbst gehostetes Modell)
Kurzlebiges signiertes Token je Mandant statt eines Anbieter-Schlüssels im Backend
/.well-known/jwks.json — damit der KI-Dienst die Token-Signatur prüfen kann
Fachmodule liegen als eigene Bausteine vor und werden beim Start geladen; ein Deployment kann Module gezielt aus- oder einschalten
Kein Treffer in diesem Bereich. Gesamte Website durchsuchen
Oft gesucht
Marketing-Cookies erlauben?
Wir würden gerne mit Google Ads messen, welche Anzeigen zu einer Anmeldung führen. Dafür werden Cookies gesetzt und Daten an Google (USA) übertragen — nur mit deiner Einwilligung. Unsere anonyme Reichweitenmessung (Matomo) läuft davon unabhängig. Details und Widerruf in der Datenschutzerklärung.