Exhibition operations
Location-scoped crew access, VIP admission and attendance reporting.
These additive endpoints are available in API 2.2.0. Availability requires the exhibition migrations and a verified deployment; local implementation does not establish production availability.
| Operation | Purpose |
|---|---|
GET /api/exhibition/operations | Organiser's event locations, pass names, assignments, invitation states and crew counts. |
POST /api/exhibition/invitations/action | Resend a pending crew invitation or cancel it for this event. |
POST /api/exhibition/zones | Create an entrance, breakout or VIP location. |
POST /api/exhibition/assignments | Assign a current organisation member to a location. |
POST /api/exhibition/assignments/replace | Replace one crew member's assigned locations with the supplied zoneIds array. |
POST /api/exhibition/admissions | Explicitly permit a confirmed event registration at a VIP location. |
DELETE /api/exhibition/assignments | Revoke a crew location assignment. |
DELETE /api/exhibition/admissions | Revoke a VIP visitor permission. |
GET /api/exhibition/crew | Read the signed-in crew member's assigned locations. |
POST /api/exhibition/scan | Validate and save a location admission. |
POST /api/exhibition/checkpoint | Resolve a checkpoint code to its event location. |
GET /api/exhibition/pass-configuration | Read organiser pass questions and zone access configuration. |
POST /api/exhibition/pass-configuration | Save or publish pass questions and zoneIds access mapping. |
GET /api/exhibition/form-analytics | Read aggregate pass-question and nationality responses. |
Organiser operations require current owner, admin or staff membership. Crew scanning additionally requires an active assignment to the selected location. Membership, registration and VIP permission are checked on the server; a QR code or a location label alone is not authority.
The scan outcome distinguishes accepted, already and denied. A repeat of the same ticket at the same location on the same Malaysian calendar day does not increase successful admissions. Only entrance scans contribute to the legacy event check-in records used by the MATRADE draft; breakout and VIP visits remain separate.
This location scanner requires a live connection. Existing legacy offline queues remain separate and must be synchronised before changing devices or origins. The online location endpoint does not certify a previously downloaded offline permission list.
POST /api/partner/team/invitations accepts optional zoneIds (and retains the
legacy singular zoneId) for a crew invitation. Each location must belong to
the inviter's organisation. Acceptance binds the pending locations to the
email-verified member once; replaying an accepted invitation must not restore
revoked access.
Operations includes event-linked crew invitations with assigned zoneIds and
expiry. Declined, cancelled and expired invitations remain visible for
organiser history; accepted crew appear in the roster. Invitation tokens are
never returned. Resend reuses the existing token and reports an actionable
error when the mail provider does not accept the message; it does not claim
inbox delivery. Cancellation expires the invitation while retaining its audit
history.
Pass forms support the eight published field types in the contracts, with required answers validated again at registration. Form analytics are aggregate counts; they do not expose another visitor's answers.
See the generated OpenAPI document for exact request and response schemas and the event-day guide.