Webhooks

🚀 Connect your ticket shop with your favorite apps!

Imagine your ticket shop could communicate with your CRM, accounting tools, or newsletter systems in real time — no more manual data exports required.

By connecting additional systems and services, the ADITUS Ticket Shop can be tailored even more precisely and powerfully to meet your specific needs. We focus on a range of standard use cases and integrations to enable fast and efficient implementations. For our customers, what truly matters is smooth execution and tangible results.

What are webhooks?

A webhook acts like a digital notification service. It is an excellent way to receive real-time updates about specific event-related transactions.

Webhooks instantly notify connected systems when important actions occur — for example, when a registration is completed or when a visitor checks in at an event.

Why use webhooks?

This real-time data flow enables immediate follow-up actions and highly personalized interactions with participants. By combining webhook events with your existing marketing infrastructure, you can:

• Trigger automated campaigns

• Update customer profiles instantly

• Launch personalized engagement journeys at the perfect moment

Webhooks empower organizations to respond immediately to visitor behavior and seamlessly integrate event data into their existing systems. The result is timely, relevant, and data-driven interactions throughout the entire event lifecycle.

The ticket shop is built around a process-driven architecture: individual actions within the purchase or registration journey (use cases) modify the shopping cart (“cart”). These changes can be understood as events — and this is exactly where webhooks can be triggered.

In principle, webhooks can be provided for all key cart-related use cases within the shop. As soon as one of these events occurs, an HTTP POST request containing a JSON payload is sent to the configured webhook URL.

Creating Webhooks

To set up a webhook, login to WebTERP and go to Start->Interfaces->Webhooks. From there, click Webhooks, then Add webhook. Alternatively, you can create and manage a webhook through the Webhooks API. Check the API documentation for detailed information.

Webhooks require a few configuration options before you can make use of them:

Payload URL

The payload URL is the URL of the server that will receive the webhook POST requests.

Content Type

Webhooks can be delivered using different content types:

• The application/json content type will deliver the JSON payload directly as the body of the POST request.

• The application/x-www-form-urlencoded content type will send the JSON payload as a form parameter called payload.

Secret

Setting a webhook secret allows you to ensure that POST requests sent to the payload URL are from ADITUS. When you set a secret, you'll receive the X-ADITUS-Signature header in the webhook POST request.

Active

By default, webhook deliveries are "Active." You can choose to disable the delivery of webhook payloads by deselecting "Active."

Events

Choose which events will send payloads for this webhook. Only subscribing to the specific events you plan on handling limits the number of HTTP requests to your server. You can change the list of subscribed events anytime.

See "Webhook event payloads" for the list of available webhook events and their payloads.

Wildcard Event

To configure a webhook for all events, use the wildcard (*) character to specify the webhook events. When you add the wildcard event, we'll replace any existing events you have configured with the wildcard event and send you payloads for all supported events. You'll also automatically get any new events we might add in the future.

Testing Webhooks

You can monitor your webhook deliveries in ADITUS WebTERP, including the HTTP Request and payload as well as the response.

Recent deliveries

Every webhook has its own "Recent Deliveries" section, which lists all occurred events and whether a delivery was successful or failed. You can also identify when each delivery was attempted.

Webhook payloads

Webhook payloads are sent as HTTP Post to the Webhook URL.

User-Agent

The User-Agent for the requests will have the prefix ADITUS-Webhook. (For future use we may choose to add a suffix.)

Delivery HTTP Headers

HTTP POST payloads that are delivered to your webhook's configured URL endpoint will contain several special headers:

Webhook payload object common properties

The common properties describes the standardized fields that are included in every webhook payload, regardless of the specific event.

Verifying the payload

If a secret is configured for a webhook, then each payload comes with a signed HMAC signature so that you can verify the origin of the webhook request. The secret is used as a key to sign the payload data with an HMAC key. The HMAC key is your security token, the HMAC digest is SHA-256, and the data is the raw payload JSON that is sent. The key is sent Base64 encoded via the X-ADITUS-Signature HTTP header.

Example Payload for cart.checkout

This example represents a maximum cart payload and therefore includes all fields that may occur in principle. Depending on the event type, article configuration, payment provider, registration flow, or legitimation setup, additional fields may appear or some fields may be omitted. The event-specific details are documented in the respective webhook descriptions.

This webhook event is triggered when a shopping cart has been successfully completed (checkout) and an order has been created.The event contains comprehensive information about the shopping cart, the order, the buyer, the articles (e.g. tickets), registration data, and payment processing. Further details about this webhook can be found in the “Ticket purchase and registration” section.

Headers:

• X-webhook-secret: whk_XY000yyXXsxxxYYYxYYYYxxxXX0zzXxX

• X-ADITUS-Event: cart.checkout

• X-ADITUS-Delivery: 8y64d70d-x103-4185-1111-000x0103y0x0

• User-Agent: ADITUS-Webhook

• Host: integration.aditus.de

• Content-Type: application/json; charset=utf-8

• Content-Length: 2067

Fields in detail:

The following tables describe the fields of the cart.checkedout webhook payload in detail.
The example values are taken from a sample payload and are intended to illustrate the structure and meaning of the individual fields. Depending on the concrete checkout scenario, some fields may be optional or only present in specific contexts.

cartCheckeout

cart – General cart information

user

event - Trade Show

items (Cart items)

Each item represents a purchased product (e.g., a ticket).

article (items[])

article prices

article prices.price / article prices.originalPrice

article image

article configuration

articleGroup

articleGroup.configuration

item price

registration

registration.data

registration answers

registration.types.self

registration.types.self.survey

registration.types.thirdPerson

legitimation

timeslots

Note: minimumNumberOfBookings and maximumNumberOfBookings are not present for every item, but they are part of the overall sample structure.

totals[] - Cart Totals

Each entry in the totals array contains the original and current pricing information.

original - Original Price

totals.original

paymentProvider

paymentMethods

paymentProvider.configuration

buyerPerson

Contains the buyer information placeholder.

buyerPerson.address

buyerPerson.surveyId

order

termsOfService

All consent/terms entries displayed during the checkout process.