Tickets, passes and profile
Where a customer finds their purchase
Section titled “Where a customer finds their purchase”| Route | What it shows |
|---|---|
/profile |
Bookings, tickets, account details |
/profile/qr/[bookingId]/[itemId] |
The QR for one booking item |
/p/[token] |
Entry pass — standalone, shareable link |
/vp/[token] |
Signing pass — standalone, shareable link |
/p/ and /vp/ render from a signed QR token verified by
@tcgkl/core/lib/utils/qr-code (verifyQRToken, verifyBookingQRToken). Both
pages are noindex: the token is the credential, so treat the URL as private —
it must not reach analytics, logs or a screenshot in a ticket.
Dates on pass pages are formatted in Asia/Kuala_Lumpur. Keep it that way;
customers read these at the venue.
What happens at the event
Section titled “What happens at the event”The pass is scanned by staff in the admin portal — entry, signing queue, payment and prize scanners each have their own screen. That side is documented in Event day, and the QR and queue internals in the signing-queue skill.
/inbox and /inbox/[id] carry messages to the customer (vendor application
threads, announcements, notifications), backed by the inbox, notifications
and vendorApplicationMessages routers.