Ticket entry and validation

In the Ticket Entry and Validation area, webhooks are used to notify external systems in real time about all relevant events related to ticket validation and access control. This enables connected applications to immediately react—for example, to trigger logging, perform security checks, or start follow-up processes.

A central example is the aserv.[*]granted event, which is triggered once an entry action has been successfully validated and granted. Similarly, aserv.[*]denied events are triggered when an action is rejected. This ensures that third-party applications are always kept up to date without requiring polling or manual queries.

Ticket validation is the core process of the entry flow. Once a ticket has been checked, the system triggers the appropriate event:

• granted events → when an action is successful

• denied events → when an action is rejected

---

Granted Events

When a process completes successfully, the corresponding granted event is triggered. This allows external systems to ensure that all downstream processes (e.g., visitor tracking, CRM updates, or security logs) are executed consistently and in real time.

Supported Granted Events

• aserv.entryGranted – Entry granted

• aserv.exitGranted – Exit granted

• aserv.blockGranted – Block successfully applied

• aserv.unblockGranted – Block successfully removed

• aserv.badgePrintGranted – Badge print granted

• aserv.badgeReprintGranted – Badge reprint granted

• aserv.customAction1Granted – Custom action 1 granted

• aserv.customAction2Granted – Custom action 2 granted

• aserv.customAction3Granted – Custom action 3 granted

• aserv.customAction4Granted – Custom action 4 granted

• aserv.customAction5Granted – Custom action 5 granted

• aserv.getHistory – Retrieve event history

Typical Use Cases:

1. A visitor scans their ticket (barcode/QR code) at an entry terminal.

2. The system validates the ticket (authorization, validity period, blocks).

3. Entry is granted (code: 0, message: "OK").

4. The system triggers the aserv.entryGranted event and sends the webhook to all registered endpoints.

5. Receiving systems can process the entry data — e.g., update visitor counts, create CRM entries, or write security logs.

Trigger Condition

• The aserv.entryGranted event is triggered when a ticket is scanned at an access control point and the entry validation is successful (Entry Granted).

Webhook payload sample for a granted entry

---

Fields in Detail

response – Result of the Entry Validation

Contains the system's decision regarding the entry request.

request – Entry Request (Scan)

Details of the actual scan operation at the terminal.

fairevent – Event Information

Information about the fair/event in whose context the entry takes place.

terminal – Access Terminal

Information about the terminal at which the scan was performed.

device – Device (within terminal)

Details about the physical device deployed at the terminal.

article – Ticket Article

Information about the article (ticket type) underlying the scanned ticket.

ticket – Ticket Information

Information about the specific ticket that was scanned.

owner – Ticket Owner (within ticket)

The person to whom the ticket belongs (registration data).

user – Ticket User (within ticket)

The user who uses the ticket (may differ from the owner, e.g., for transferred tickets).

user – System User (Top-Level)

The user who physically performed the scan at the terminal (e.g., security personnel or an automated device account).

Note on Additional Events

The same payload structure applies analogously to all other Granted events in the Ticket Entry and Validation area. Only the value of the event field and the command value in request change:

Denied Events

When an action is rejected, the system triggers the corresponding denied event. This allows security mechanisms, monitoring systems, or user feedback processes to be executed immediately and reliably.

For Denied events (e.g., aserv.entryDenied), the response object contains a code ≠ 0 and a corresponding error message in the message field.

Supported Denied Events

• aserv.entryDenied – Entry denied

• aserv.exitDenied – Exit denied

• aserv.blockDenied – Block operation failed

• aserv.unblockDenied – Unblock operation failed

• aserv.badgePrintDenied – Badge print denied

• aserv.badgeReprintDenied – Badge reprint denied

• aserv.customAction1Denied – Custom action 1 denied

• aserv.customAction2Denied – Custom action 2 denied

• aserv.customAction3Denied – Custom action 3 denied

• aserv.customAction4Denied – Custom action 4 denied

• aserv.customAction5Denied – Custom action 5 denied

Webhook payload sample for a denied entry

Depending on the reason for the denial, not all data is available in the response.

Note on Additional Denied Events

The same payload structure applies analogously to all other Denied events. Only the value of the event field and the command value in request change:

Key Differences from Granted Events