> ## Documentation Index
> Fetch the complete documentation index at: https://dokumentation.websale.de/llms.txt
> Use this file to discover all available pages before exploring further.

# ASSE interface (server-side events)

> Send shop data asynchronously over HTTPS to external systems via WEBSALE ASSE server-side events using configurable event IDs and target URLs.

Via the ASSE interface (Asynchronous Server-Side Events), arbitrary data can be transmitted asynchronously from the shop via HTTPS to external systems (e.g. newsletter, search, or tracking services). The transmission takes place on the server side (shop server → recipient server) and independently of the client.

There is no classic API endpoint that is "called" externally. Instead, a configured event in the shop is triggered, which executes an asynchronous HTTP request to a defined target URL.

***

## Provision in the shop

The ASSE interface is a standard part of every WEBSALE shop and can generally be used.

OR

ASSE must be enabled/activated in the shop (optionally per subshop).

***

## How it works

* The transmission takes place on the server side from the shop server to the recipient server (not from the client/browser)
* Communication takes place exclusively via HTTPS
* The execution is asynchronous: triggering does not block the shop process, even if the target system does not respond
* Multiple events/targets can be configured
* For each event, the transmission can be carried out via an HTTP request with a different method (e.g. GET/POST/PUT)

***

## Event configuration

Any number of events can be configured for the ASSE interface. Each event is uniquely addressed via an event ID (this ID is used when triggering).

The configuration is done via the configuration node [general.asse](https://websaleag-44ee7ea6.mintlify.app/konfiguration/general-allgemeine-shopeinstellungen#4-general-asse-schnittstelle-für-asynchronous-server-side-events-asse)

***

## Use in templates (brief overview)

In templates, the module [\$wsAsse](/en/frontend/referenz/module/wsasse) is available.

With `$wsAsse.fire(<eventId>, <data>)`, an event is triggered and an asynchronous HTTP request is executed based on the stored event configuration.

* Return: `true` if the event was successfully triggered; `false` in case of configuration problems. However, `true` does not mean that the request has already arrived successfully at the recipient (asynchronous).
* `data` is not URL-encoded (must be done manually if needed)
* If a list or an object is passed, it is converted as JSON

### List configured events (determine event IDs)

If the event ID is not known or you do not want to look into the configuration.

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{{
  foreach $event in $wsAsse.asseConfigs:
    print $event.id;
  /foreach
}}
```

### Trigger event (fire)

An event can only be triggered if it was previously created in the configuration [general.asse](https://websaleag-44ee7ea6.mintlify.app/konfiguration/general-allgemeine-shopeinstellungen#4-general-asse-schnittstelle-für-asynchronous-server-side-events-asse).

#### Example

```html theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
{{
  var $eventData = "userid=" + $userAccount.id;
  var $triggered = $wsAsse.fire("myevent", $eventData);
}}
```

* A payload is built: `userid=<ID of the logged-in user>`
* The configured event `myevent` is triggered
* The return value `true` only means: the event was triggered — not that the HTTP request was already successful at the target.
* `$eventData` is not automatically URL-encoded (so special characters/spaces, for example, must be encoded yourself beforehand if needed)
* Depending on the configured HTTP method, `$eventData` is transmitted as part of the URL (e.g. with GET) or as a request body (e.g. with POST/PUT/PATCH) (according to ticket text)

For more information, see the module reference [\$wsAsse](/en/frontend/referenz/module/wsasse).

***

## Success criteria, retries, and timeouts

Since the transmission is asynchronous, transmission errors are not necessarily immediately visible in the shop.

In order for the delivery to be considered "successful", check mechanisms / conditions can be defined (e.g. HTTP status code, content type, or response contents).

If conditions are not met, retry attempts with delay and timeout are carried out — depending on the configuration.

***

## Log manager

Content to follow.