Use Case – Delta Sync
Note:
If the includingTicketOwnerUpdates parameter is set to true, all update actions for the ticket owner are included. Use this option only for delta loads. Do not set it for initial, full loads, as this increases execution time and the chance of potential time-out errors during execution.
Once all data has been loaded initially, the parameter can be used for subsequent delta loads. This minimises the chance of potential time-outs.
This endpoint enables high-throughput bulk retrieval of personal data for trade-fair events, including both event-specific and ticket-specific attributes. The endpoint supports delta queries based on registration events, ensuring that only records created or updated since the last retrieval are returned. The endpoint is optimised for incremental data pulls and also supports an initial full load of all data. The initial full load must not be executed more than three times per calendar day per event. Data selection is driven by registration-related events (such as create or update), which serve as the reference for delta determination. The scenario (initial load or delta) is controlled via the sinceRegistrationId query parameter.
User-Rools
To use this use case, the user must have the following role assigned.
-
Required role
- ApiAttendeeBatch
-
Optional role
- ApiAttendeeWithAdditionalSalesInformation
Role- and Article-Based Data Access
-
Fine-grained access control:
Third parties can only access attendee registrations for the specific badge categories (articles) and user roles that have been explicitly granted to them. For example, a matchmaking provider may only receive data for VIP and EXHIBITOR categories. -
Standardised roles:
The API supports a standard set of badge category roles, such as Visitor, Exhibitor, Press, Services, and more. If there are additional badge categories in the system used, corresponding roles must also be created in the system. Please note the naming convention for roles!
Example roles include:-
ApiAttendeeBadgeCategoryCONTRACTOR
-
ApiAttendeeBadgeCategoryCREW
-
ApiAttendeeBadgeCategoryDELEGATE
-
ApiAttendeeBadgeCategoryEXHIBITOR
-
ApiAttendeeBadgeCategoryMEDIA
-
ApiAttendeeBadgeCategoryORGANIZER
-
ApiAttendeeBadgeCategoryPRESS
-
ApiAttendeeBadgeCategorySPEAKER
-
ApiAttendeeBadgeCategorySPONSOR
-
ApiAttendeeBadgeCategorySTAFF
-
ApiAttendeeBadgeCategorySTUDENT
-
ApiAttendeeBadgeCategoryVIP
-
ApiAttendeeBadgeCategoryVISITOR
-
ApiAttendeeBadgeCategoryNONE
- for all articles that do not have a BadgeCategory
-
If one of these new roles is configured, all other articles will be filtered out. BadgeCategory roles can be combined.
Block-Scoped Payloads
-
Modular response structure:
The API response is organised into logical blocks (such as attendee, address, customFields, termsOfService, ticket, article, booth, exhibitor, additionalSalesInformation).
Each block can be enabled or disabled based on the assigned user role. -
Default behaviour:
If no specific role configuration is set, a baseline set of blocks is returned (e.g., attendee, address, customFields, ticket, article, booth, exhibitor)- the same as before version 4.135
-
Full access roles:
Special roles are available to grant full access to all attendee or ticket blocks:-
ApiAttendeeWithAttendeeFullAccess (includes all attendee-related blocks)
-
ApiAttendeeWithAttendeeInformation
-
ApiAttendeeWithAddressInformation
-
ApiAttendeeWithCustomFieldsInformation
-
ApiAttendeeWithTermsOfServicesInformation
-
ApiAttendeeWithUserInformation
-
-
ApiAttendeeWithTicketFullAccess (includes all ticket-related blocks)
-
ApiAttendeeWithTicketsInformation
-
ApiAttendeeWithArtcleInformation
-
ApiAttendeeWithBoothInformation
-
ApiAttendeeWithExhibitorInformation
-
ApiAttendeeWithBarcodeInformation
-
ApiAttendeeWithTicketLinksInformation
-
ApiAttendeeWithTicketPromotionCodesInformation (available from version 139 or later)
-
ApiAttendeeWithTicketSalePropertiesInformation (available from version 139 or later)
-
-
If one of these new roles is configured, all other areas that are not configured will be deactivated. Roles can be combined.
Response
The response is delivered in JSON format and contains information about the event, personal data of the ticket holder, and information about the tickets.
If the number of registrations exceeds the limit, use the maxRegistrationId from the response payload in the optional query parameter sinceRegistrationId to retrieve the next set of registrations. For a delta query, also use the sinceRegistrationId query parameter to retrieve only those attendees registered after the specified registration event.
Performance Note
The delta or batch query returns up to 2,500 records per request by default (limit, default: 2500). For most customers and events, this value is optimal. In rare cases (such as high system or database load, an unfavourable SQL Server execution plan, or very large data volumes), the request may time out.
Recommendation: Reduce the limit manually and use smaller pages until the query reliably returns results without timing out.
Authentication#auth
This endpoint does not require authentication.
Headers#headers
Query parameters#query
Represents an offset for registrations that have already been transmitted. A full-load (sinceRegistrationId = 0) should only be carried out once a day, not more than 3 times a day.
(Optional) Number of items per response. Default value : 2500 A high limit can cause the request to time out if it takes longer than 30 seconds. Please choose the limit accordingly.
If set to true, all update actions for the ticket owner will also be included. Only for delta loads. Do not set it for initial, full loads.
If true, all cancellation ticket events are also returned. This can lead to duplication of individual registrations.
If true, all blocked ticket events are also returned. This can lead to duplication of individual registrations.