Skip to main content
Das Storefront API Session-Handling stellt Funktionen bereit, um Sessions in der Storefront zu erstellen und zu verwalten. Damit lassen sich Benutzerzustände (z. B. anonymer Besuch oder eingeloggter Kunde) sowie sessiongebundene Daten wie Warenkorb und Merkliste konsistent über mehrere Requests hinweg nutzen. Die Session ist ein Bestandteil des Shops und zwingend erforderlich. Weiteren Informationen dazu finden Sie hier.

​
Unterstützte Methoden

Angabe aller unterstützten Methoden.

​
Methoden für das Session-Handling

Diese Methoden kümmern sich um das Session-Handling zwischen API und Storefront: Zunächst werden neue Session-IDs als technische Grundlage für alle weiteren API-Aufrufe erzeugt. Bei Bedarf werden vollständige Weiterleitungslinks zu Template-Seiten (z. B. Checkout) inklusive Übergabe der aktuellen Session aufgebaut. Über optionale Parameter lassen sich Zielseiten gezielt steuern (z. B. ein bestimmter Checkout-Schritt oder Hervorhebungen), während die eigentliche Session-ID sicher im Link eingebettet wird.

​
POST session/create

Folgender Aufruf erstellt eine Session-ID.
Mehr Infos dazu: Storefront API Basics

​
Beispiel-Response

​
POST session/prepareRedirect

Folgender Aufruf erzeugt einen vollständigen Link zu einer Template-Seite (z. B. checkout.htm) und übernimmt die aktuelle Session in die Storefront. Die Verwendung dieser Methode ist sinnvoll, wenn Ihr Shop gemischt aufgebaut ist, d. h., wenn einige Teile mit dem WEBSALE-Template Theme und andere Teile mit der Storefront-API erstellt wurden. Der Endpunkt stellt sicher, dass beide Teile dieselbe Session verwenden. Beispiel-Request, der einen vollständigen Link zur Template-Seite checkout erstellt und dabei die aktuelle Session mitnimmt

​
Parameterübersicht

Beispiel mit parameters
Die Zielseite liest den Wert im Template aus:
Werte in der Ziel-URL steuern Sie nicht hier, sondern in der Konfiguration. Es gibt zwei gleichnamige parameters:
  • parameters im Konfigurationsknoten storefrontApi.redirects wird an die Ziel-URL als Query-Parameter angehängt und ist im Template wie jeder andere URL-Parameter verfügbar, z. B. über $wsViews.current.paramList.
  • parameters im Request-Body dieses Endpunkts wird in der Session hinterlegt und erscheint nicht in der URL.
Faustregel: Soll der Wert in der Adresse stehen oder die angezeigte Seite bzw. den Schritt bestimmen, gehört er in die Konfiguration. Soll er nur dem Template bekannt sein, gehört er in den Request-Body.

​
Beispiel-Response

(vollständige URL zur Ziel-Template-Seite inkl. Session-Übergabe)
Der zurückgegebene Link ist 30 Sekunden gültig. Danach lässt sich die Session darüber nicht mehr übernehmen: Der Shop legt in diesem Fall eine neue, leere Session an — ohne Fehlermeldung. Der Kunde sieht dann beispielsweise einen leeren Warenkorb im Bestellablauf.Rufen Sie session/prepareRedirect deshalb erst unmittelbar vor der Weiterleitung auf, also z. B. im Klick-Handler der Schaltfläche „Zur Kasse”, nicht auf Vorrat beim Aufbau der Seite.
Öffnen Sie den Link per echter Browser-Navigation, also über window.location.href, einen normalen Link oder eine serverseitige Weiterleitung. Ein Aufruf per fetch bzw. XMLHttpRequest genügt nicht: Der Kunde muss auf der Zielseite landen, damit der Shop dort die Session übernehmen kann.

​
Fehlercodes

Mehrstufige Zielseiten. Ist die Ziel-Vorlage mehrstufig aufgebaut — etwa ein Bestellablauf mit den Schritten Adresse, Zahlung, Übersicht und Abschluss — wählt sie den anzuzeigenden Schritt in der Regel über einen URL-Parameter. Dieser Parameter muss in storefrontApi.redirects hinterlegt sein, damit der erzeugte Link ihn enthält. Fehlt er, ruft der Kunde die Seite ohne Schrittangabe auf und die Vorlage zeigt statt des Formulars ihren allgemeinen Hinweistext. Der Aufruf wird dabei regulär mit HTTP 200 beantwortet, es entsteht keine Fehlermeldung. Welchen Parameter Ihre Vorlage erwartet, klären Sie bitte mit Ihrem Template-Ansprechpartner.