The attendee app is bound to one organization at build time. Everything else about how it behaves — which events exist, who may enter where, which emails go out — is data in that organization.
Organization and site
The app's orgId doubles as siteName. The server uses the site to work out the customer-facing web host, and builds the links in ticket and booking emails from it. That is why the app sends no host header of its own: the website is the canonical home for those links, not the API.
Production is organization eventos; development uses demo, the shared sandbox organization, which is why demo data (events, participants, posts) from other products shows up there.
Event-level settings
Most behaviour is per event, not per organization. settings on the event record covers networking, leads, check-in requirement, QR rotation and its interval, walk-ins, approval and per-session caps. See event setup.
Notification settings
Base-setting keys read by the events, reservations and storefront modules:
| Key | Purpose |
|---|---|
notificationCopyTo | Copy recipients per module; the reservation copy defaults to the organization email unless set to false |
systemEmail | From-address for platform email |
systemPhone, systemSmsPhone | Sending numbers for SMS |
Templates themselves are edited in Studio Manager. See notifications.
What needs no token
These routes are marked public on the server and work with the app token alone. Everything else requires a signed-in customer.
/client/eventsNo auth/client/events/:eventIdNo auth/client/events/:eventId/ticket-typesNo auth/client/events/:eventId/sessionsNo auth/client/events/:eventId/scheduleNo auth/client/events/:eventId/mediaNo auth/client/events/bookingNo auth/client/events/tickets/purchaseNo auth/client/events/tickets/confirm-orderNo auth/client/events/stripe/configNo auth/client/events/stripe/intentNo auth/client/community/feedNo auth/client/community/posts/:postIdNo auth/client/community/posts/:postId/commentsNo auth/client/community/pagesNo auth/client/community/pages/:pageId/announcementsNo auth/client/community/storiesNo auth/client/community/people/:emailNo auth/client/community/hashtags/trendingNo authParticipants (GET /client/events/:eventId/participants), tickets, the wallet, connections, messages, notifications, bookmarks, follows, meetings and media uploads all require the customer token.
The feed is public, but viewerLiked and viewerSaved are only stamped when a customer token is present. The app sends it; a browser hitting the route anonymously sees the posts without those flags.
Rate limiting
The API applies one global limiter: a 15-minute window with RATE_LIMIT_MAX requests per client address (default 10,000). Preflight requests and the health check are exempt. A burst from scripted tests on one address returns 429 Too Many Requests; the app on a phone is not affected by a developer's laptop hitting the limit. TRUST_PROXY_HOPS (default 2) controls how the client address is read behind a proxy.
Server variables
Environment variables the events, community, reservations and related modules read:
| Variable | Used for |
|---|---|
SHARED_ORG, ROOT_ORG | Fallback organizations for shared configuration |
NODE_ENV | Production toggles, including secure link schemes |
GOOGLE_MAPS_API_KEY | Address and venue lookups |
VIDEOSDK_API_ENDPOINT | Virtual meeting tokens for reservations |
RESERVATION_REMINDER_TEST_MODE | Shortens reminder offsets for testing |
JWT_SECRET | Token signing |
RATE_LIMIT_MAX, TRUST_PROXY_HOPS | See above |
Push for the staff softphone uses a separate set (APPMINT_FCM_SERVICE_ACCOUNT_JSON_BASE64, APPMINT_APNS_VOIP_*, APPMINT_APNS_SANDBOX); the attendee app does not use them.