Für jede Schnittstelle zum LINA Store müssen zunächst die passenden Endpunkte in der LINA Third Party API (TPAPI) lizenziert sein. Welcher unserer Schnittstellenpartner welche Endpunkte benötigt, ist bei der jeweiligen Schnittstelle beschrieben.  
Siehe die Kategorie LINA (Schnittstellen/LINA) im Handbuch.


Der Aufruf für die LINA data API ist geändert, die alte URL amadeus360 ist noch erreichbar. Bitte auf die neue URL umstellen.
https://api.lina.de/ ...


Verfügbare Endpunkte mit Funktion

NameDokumentationFunktion
Stammdaten /Wareneinsatz

merchandisemanagement		Endpunkt Artikelstammdaten VerkaufsartikelErmöglicht das Erstellen oder Aktualisieren von Verkaufsartikeln in der Warenwirtschaft
  • inklusive der Rezepturen
  • inklusive MEC-Codes und Sparten
Bewegungsdaten Umsatz, Kassenmodul

revenuejournal_read		Endpunkt Umsatzdaten KasseExport der Journaldaten des Kassensystems
POS API Webkasse*
Artikelbuchung, -bezahlung und Tischreservierung

webcashregister		Endpunkt POS: ASQL

ratelimit 100 Datenanfragen pro Laden und 15 Minuten		Funktionalität der LINA Kasse
  • Bonieren und Bezahlen mit der vollen Tischfunktionalität 
  • Steuerung mit ASQL
  • Tischreservierung
Personal
personal_read		Endpunkt PersonalPersonaleffizienz
Arbeitnehmerzertifikate
Schulungszeiten
BWA
bwa_read		Endpunkt BWAHerunterladen der BWA-Daten
DFKA-Taxonomie Import
taxonomie_import		Endpunkt DFKA-TaxonomieHochladen eines vollständigen Datensatzes DFKA
Online-Gutscheine

Endpunkte Gutscheine


Gutscheine in 2 Varianten

  • Andere Systeme nutzen LINA Online-Gutscheine 
  • Gutscheine verschiedener Anbieter in LINA Kasse einlösen




*Für den Endpunkt 'POS /Webkasse' muss zwingend zusätzlich ein Modul POS API "Webkasse" lizenziert, registriert und synchronisiert werden. Der Fachhandelspartner konfiguriert diese zusätzliche Kasse.



http-request example /Beispiel Artikelstamm

nativer http-request im Browser an den Webservice in LINA

GET ... /extern/merchandiseman/index

Beispielabfrage mit OAuth Access-Token

Eine korrekte Anfrage in cURL übergibt das Access-Token im Authorization-Header. Das Access-Token muss bei allen Abfragen mit gesendet werden.

curl -i -H "Accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer f5eac38d0a41f1ecb882bd9240a16cddd838c5f3" -X GET ... /extern/merchandiseman/index


Anfrage-Header:

NameBeispielwertBeschreibung
Authorizationb18f0405b7d8dfdaa6702b9295064e769924eac8Das zuvor erzeugte Access-Token (Zugriffs-Token). Vor dem Access-Token darf auch noch Bearer stehen, muss es jedoch nicht.


JSON-Antwort

Als Antwort auf obige Anfrage erhalten Sie immer ein JSON-Objekt bzw. JSON-Array.


Antwort bei Erfolg

In der Antwort erhält man z.B. Daten eines Artikels als JSON-Objekt:

[
    {
        "number": 1234,
        "name": "Testartikel",
        "function": "MAIN",
        "prices": [
            {
                "active": true,
                "priceperunit": 100,
                "pricefixed": 5,
                "menucard": 0,
                "site": 0
            }
        ]
    }
]

Antwort bei Fehler

Die durchgehende Behandlung von Fehlermeldungen ist essentiell für eine zuverlässige Programmierung der TP API.

{
    "status": "error",
    "message": "Not authenticated."
}


Beispiel: Abfrage des aktuellen Betriebes

Um gerade für Partner, die Endpunkte für mehrere Betriebe ansprechen, herausfinden zu können, welcher Client/Token für welchen Betrieb gilt, kann in jedem Endpunkt eine Abfrage an "store" geschickt werden.


GET ... /extern/merchandiseman/store


In der Antwort erhält man Daten des aktuellen Betriebes sowie den aktuellen Client als JSON-Objekt:

{
    "name": "Gastro-MIS GmbH",
    "mail": "info@gastro-mis.de",
    "token": {
        "access_token": "<AccessToken>",
        "client_id": "<ClientID>",
        "expires": "1649016198",
        "scope": "merchandisemanagement_read,merchandisemanagement_write,revenuejournal_read,taxonomie_import,personal_read,webcashregister_write,bwa_read"
    }
}