November & December 2025

N200 / GES – Profile Picture URL for Accounts
See visitor photos directly in N200 / GES exports.
The profilePhotoUrl parameter now passes the account’s profile picture URL so connected systems can display the same photo used in ExpoPlatform.

How it works

• A new GES parameter profilePhotoUrl is populated with the user’s profile picture URL.

• Integrations that consume this parameter can render the image alongside attendee data.

• No change to existing fields or mappings.

Why it’s helpful

• Keeps visual identity consistent between ExpoPlatform and N200 / GES.

• Makes it easier to recognise people in external systems and on-site tools.

• Adds richer data to downstream reporting without extra configuration.

Event List API – GET /api/v3/events
Retrieve all events in your environment with a single call.
A new Event List endpoint exposes key details (id, title, dates, active state) for events via API v3.

How it works

• Method: GET /api/v3/events

• Optional query parameter: active (true / omitted).

  • If not set → returns all events (active + inactive).

  • If active=true → returns only active events.

• Response: JSON array of event objects with id, title, start, end, and active.

Why it’s helpful

• Makes it easy to sync or list events in external tools.

• Reduces the need for custom queries or manual exports.

• Provides a consistent v3 contract for event discovery.

Meeting Limits with Auto-Confirm Meetings (Compliance)
Auto-confirmed meetings now fully respect exhibitor limits.
Meeting limits set for exhibitor categories are enforced even when auto-confirm is enabled, so exhibitors can’t exceed their allowed number of meetings.

How it works

• Category-level meeting limits (e.g. “Basic – 10 meetings”) are applied when auto-confirm is ON.

• Auto-confirmed requests are stopped once the limit is reached.

• The remaining meeting count aligns with the configured cap.

Why it’s helpful

• Prevents accidental overbooking when auto-confirm is enabled.

• Protects premium tiers and sponsorship packages that rely on strict limits.

• Keeps capacity management and reporting consistent across all confirmation modes.

Exhibitor Categories API – GET /api/v3/exhibitors/{eventId}/categories
Fetch exhibitor categories for an event via API v3.
A new endpoint exposes all exhibitor categories (with order and default flags) for a given event.

How it works

• Endpoint: GET /api/v3/exhibitors/{eventId}/categories

• Required parameter: eventId (path).

• Returns an array of category objects with:

  • id – category ID

  • name – category name

  • orderNum – sort order

  • default – whether it’s the default category

Why it’s helpful

• Standardises how integrations retrieve exhibitor categories.

• Supports external tools that need to map exhibitors to the same category structure as ExpoPlatform.

• Respects organiser-defined ordering and defaults.

Participant Categories API – GET /api/v3/participants/{eventId}/categories
Expose participant categories for an event via API v3.
This endpoint returns all participant categories configured for an event, including order and default flags.

How it works

• Endpoint: GET /api/v3/participants/{eventId}/categories

• Required parameter: eventId (path).

• Returns an array of participant category objects with:

  • id – category ID

  • name – category name

  • orderNum – sort order

  • default – whether it’s the default category

Why it’s helpful

• Gives external systems a single source of truth for participant segments.

• Simplifies category-based logic in integrations and reporting.

• Keeps category ordering consistent with what organisers see in Admin.

ExpoFP – New Stand Format Support in Apps
Support “Hall + Stand” format for ExpoFP stands in mobile apps.
The mobile app now understands the new ExpoFP stand format so exhibitors and stands match correctly even when hall names are included.

How it works

• New Admin setting: “Map with Hall” in General settings → ExpoFP integration.

• This setting is passed to the app via the getExhibiton endpoint.

• If Map with Hall = false:

  • Behaviour stays the same – app uses stand name only (e.g. G61).

• If Map with Hall = true:

  • App merges Hall + space + Stand (e.g. Halle 3.0 G61) to match ExpoFP.

  • Lookups between ExpoPlatform and ExpoFP use this combined value.

Why it’s helpful

• Ensures consistent exhibitor–stand matching across web and mobile.

• Supports venues and floorplans that require hall information.

• Gives organisers flexibility to choose the mapping approach per event.

Accounts – Custom Questions Endpoint in API v3
Retrieve registration custom questions via API.
A new endpoint api/v3/account/getcustomquestions exposes custom questions configured in the Visitor Registration pipeline.

How it works

• Endpoint: api/v3/account/getcustomquestions

• Required input: Event ID.

• Returns a structure containing:

  • eventId

  • questions – array of objects where each object holds:

    • a field key (e.g. select_123) mapped to the question text,

    • option labels mapped to internal option identifiers (e.g. "Buyers": "option-1").

Why it’s helpful

• Lets external tools understand available custom questions and options.

• Simplifies mapping responses from accounts to the right questions.

• Keeps registration logic and integrations synced around the same schema.

Deleted Participants – Dedicated Retrieval by Event and Time
Fetch deleted participant IDs via API.
Support for deleted users in participant list API has been extended with a dedicated endpoint to retrieve IDs of deleted participants.

How it works

• Original enhancement proposed a deleted_users boolean parameter and a deleted_user_ids array in /api/v2/participants/{eventId}/list.

• New requirement:

  • A new endpoint has been introduced to return a list of deleted participant IDs.

  • The endpoint supports filtering by eventId and time.

• Admin-side description was adjusted accordingly.

Why it’s helpful

• Makes it easier for external systems to stay in sync when participants are deleted.

• Avoids reprocessing full participant lists just to detect removals.

• Supports cleaner, more accurate downstream databases.

Invoice Payment for Participants in Registration
Let participants choose “Pay by Invoice” during registration, with activation after payment confirmation.
Invoice payments are now supported in the current (old) Registration UI, gating profile activation until organisers confirm invoice payment.

How it works

• New toggle in Admin → Event Setup → Payment → General:

  • “Allow payment with Invoice in Registration” (default OFF).

  • OFF → registration shows card payment only.

  • ON → Summary step shows Pay by card | Pay by invoice (if there is at least one paid item).

• When Pay by invoice is chosen:

  • Registration is submitted without card payment.

  • The profile is not activated yet.

  • Paid sessions selected during registration are still added to the schedule after submission (no need to wait for payment approval).

• Emails (fallback option in scope):

  • No special “Registration with Invoice” email is sent.

  • Participant receives the standard registration email with activation link only after organiser confirms invoice payment.

• Payment confirmation:

  • In Admin → Event Setup → Payments → Invoice payments, organiser confirms invoice payment.

  • Confirmation triggers the standard Registration email with Activation Link.

• If the summary becomes free (e.g. discounts remove all charges), invoice option is hidden and the flow proceeds as a free registration.

• Turning the toggle OFF mid-event doesn’t affect existing pending invoice registrations; it only impacts new registrations.

Why it’s helpful

• Enables invoice-based payments for visitors using the legacy registration UI.

• Ensures access is only granted after invoice payment is confirmed.

• Keeps paid session allocation aligned with what participants selected during registration.