GETADITUS/Attendees/Use Case Examples/Use Case – By Email

Use Case – By Email

GET{{API_BASE_URL}}/terp/v1/events/{{EVENT_ID}}/attendees?eMail=a.ditus@aditus.de

This endpoint is used to retrieve specific personal data for an attendee of a fair event who is identified by their e-mail address. This data contains details about the event and the ticket that was purchased.

User-Rools

To use this use case, the user must have the following role assigned.

  • Required role

    • ApiAttendeeGetByEmail
  • 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.

With externalId

There can be many attendee data records for the same person for one e-mail (duplicates), this can have different reasons depending on the process.

When selecting the best possible attendee data record, the Attende API behaves as follows:

  1. all attendees with the email as a contact are determined

  2. it is checked whether a user account has also been assigned to a data record

  3. the attendee data records are sorted in descending order of recency

The attendee API selects the corresponding attendee data records in this order.
An attendee data record with a user account is always preferred!

This behaviour can ensure that the attendee data record is not returned as expected, for example after a previous import.

In addition to the e-mail, up to 3 external-IDs can be specified. With this information, exactly the attendee data record that was requested can be transmitted. This means that only the tickets where the attendee data record is also the owner are given out.

Authentication#auth

This endpoint does not require authentication.

Headers#headers

Acceptapplication/json

Query parameters#query

eMaila.ditus@aditus.deoptional
externalId1{{externalId1}}optional

(Optional) See With externalId

externalId2{{externalId2}}optional

(Optional) See With externalId

externalId3{{externalId3}}optional

(Optional) See With externalId

includingCancellationsfalseoptional

(Optional) When set to true, the response includes cancelled tickets in addition to non-cancelled tickets. When false (or omitted), cancelled tickets are excluded from the result set.

includingBlockedTicketsfalseoptional

(Optional) When set to true, the response includes blocked tickets in addition to non-blocked tickets. When false (or omitted), blocked tickets are excluded from the result set.

Responses#responses

200OKUse Case – By Email